Content Visibility

Holds information pertaining to the visibility for a piece content, which includes things like the access level (consumer roles) required to consume it and its publish state and date.

Content Visibility and Publishing

The ContentVisibility structure is related to the publishing process. The overall domain model has been thought to allow the following publishing method:

One Asset Associated to Multiple Content Details Objects

This method is meant to support the sharing of content across different editorial groups, but addressing the fact that editors from different groups may want to have a different set of metadata/tagging for the same asset. Each editorial group will have their own set of content details, that they can modify and publish as desired, without affecting the metadata and publishing state/date of the same asset in other properties.


Use Case: One Asset Shared Across Different Properties

An example of this is a video created by the editorial team of a club, which they can publish whenever they want to their site. And they can decide to submit the same video to and/or NFL Now. The and NFL Now editorial teams will have a copy of the video in their systems, that they can update/delete/publish/unpublish at their discretion in their specific platforms.

Description of the Content Generation Workflow

Use Case: One Asset with Multiple Purposes within the Same Property

An example of this is an image that can be, at the same time, used in a photo gallery, as the thumbnail for an article, the logo for a channel, the still image for a video and the cover for a photo essay.

Description of the Content Generation Workflow

Content Visibility and Fan-Facing Client Applications

The ContentVisibility details are used by the API Services to determine if an incoming request has the required access rights to a specific piece of content. Requests coming from fan-facing client applications will need to provide information about the client and the fan user making the request, which will be compared against the consumerRoles and determine the appropriate response.

Description of the Content Retrieval Workflow


Name Default Field Type Description
consumerRoles * List<Role> The list of roles that can consume the content, to be used by fan-facing client applications.
promotionLevel * PromotionLevel Indicates if the content is included in any promotional campaign.
publishState * PublishState The publish state of the content in the system.
originalPublishDate * DateTime The date the content is originally published. By default it is always the date of the very first publishing of the content, but it can be modified by editorial as desired. Expressed in ISO-8601 format.

Default Sorting Field : N/A

Promotion Level - Enum

Value Description
FOR_SALE The content is available for sale, e.g.: photos in a gallery that can be bought through a partner like ReplayPhotos.
NONE This is the default value, indicating that the content is not included in any promotional campaign.

Publish State - Enum

Value Description
WORK_IN_PROGRESS Content is being worked on by the editorial team and it is not available for consumption by fan-facing client applications.
PUBLISHED Content has been enabled by the editorial team for consumption by fan-facing client applications.
SCHEDULED Content has been scheduled for auto-publishing at a date/time in the future, until then it is not available for consumption by fan-facing client applications.

JSON Representation

    "consumerRoles": [
            "id": "b14de636-7eff-487e-b615-132215be1436"
    "promotionLevel": "FOR_SALE",
    "publishState": "PUBLISHED",
    "originalPublishDate": "2015-02-01T20:03:12.035-08:00"