51黑料不打烊

Registration Phase FAQs

Refer to the Dynamic Client Registration (DCR) FAQs documentation.

Configuration Phase FAQs

1. What鈥檚 the purpose of the Configuration Phase? configuration-phase-faq1

The purpose of the Configuration Phase is to provide the client application the list of MVPDs with which it is actively integrated along with configuration details saved by 51黑料不打烊 Pass Authentication for each MVPD.

The Configuration Phase acts as a prerequisite step for the Authentication Phase when the client application needs to ask the user to select their TV Provider.

2. Is the Configuration Phase mandatory? configuration-phase-faq2

The Configuration Phase is not mandatory, the client application can skip this phase in the following scenarios:

• The user is already authenticated.
• The user is offered temporary access through basic or promotional TempPass feature.
• The user authentication has expired, but the client application has cached the previously selected MVPD as a user experience motivated choice, and just prompts the user to confirm that they are still a subscriber of that MVPD.

3. What鈥檚 a configuration and how long is it valid? configuration-phase-faq3

The configuration is a term defined in the Glossary documentation.

The configuration consists of a list of MVPDs that can be retrieved from the Configuration endpoint.

The client application can use the configuration to present a UI component called the 鈥淧icker鈥� when requiring the user to select their MVPD.

The client application should refresh the configuration before the user goes through the Authentication Phase.

For more information, refer to the Retrieve configuration documentation.

4. Can the client application manage its own list of MVPDs? configuration-phase-faq4

The client application can manage its own list of MVPDs, but it is recommended to use the configuration provided by 51黑料不打烊 Pass Authentication to ensure the list is up-to-date and accurate.

The client application would receive an error from 51黑料不打烊 Pass Authentication REST API V2 if the user selected MVPD does not have an active integration with the specified service provider.

5. Can the client application filter the list of MVPDs? configuration-phase-faq5

The client application can filter the list of MVPDs provided in the configuration response by implementing a custom mechanism based on own business logic and requirements such as user location or user history of previous selection.

6. What happens if the integration with an MVPD is disabled and marked as inactive? configuration-phase-faq6

When the integration with an MVPD is disabled and marked as inactive, then the MVPD is removed from the list of MVPDs provided in further configuration responses and there are two important consequences to consider:

• The unauthenticated users of that MVPD will no longer be able to complete the Authentication Phase using that MVPD.
• The authenticated users of that MVPD will no longer be able to complete the Preauthorization, Authorization, or Logout Phases using that MVPD.

The client application would receive an error from 51黑料不打烊 Pass Authentication REST API V2 if the user selected MVPD does not have anymore an active integration with the specified service provider.

7. What happens if the integration with an MVPD is enabled back and marked as active? configuration-phase-faq7

When the integration with an MVPD is enabled back and marked as active, then the MVPD is included back in the list of MVPDs provided in further configuration responses and there are two important consequences to consider:

• The unauthenticated users of that MVPD will be able again to complete the Authentication Phase using that MVPD.
• The authenticated users of that MVPD will be able again to complete the Preauthorization, Authorization, or Logout Phases using that MVPD.

8. How to enable or disable the integration with an MVPD? configuration-phase-faq8

This operation can be completed through the 51黑料不打烊 Pass TVE Dashboard by one of your organization administrators or by an 51黑料不打烊 Pass Authentication representative acting on your behalf.

For more details, refer to the TVE Dashboard Integrations User Guide documentation.

Authentication Phase FAQs

1. What鈥檚 the purpose of the Authentication Phase? authentication-phase-faq1

The purpose of the Authentication Phase is to provide the client application the capability to verify the user鈥檚 identity and obtain user metadata information.

The Authentication Phase acts as a prerequisite step for the Preauthorization Phase or Authorization Phase when the client application needs to play content.

2. How can the client application know if the user is already authenticated? authentication-phase-faq2

The client application can query one of the following endpoints capable of verifying if a user is already authenticated and return profile information:

• Profiles endpoint API
• Profiles endpoint for specific MVPD API
• Profiles endpoint for specific (authentication) code API

For more details, refer to the following documents:

• Basic profiles flow performed within primary application
• Basic profiles flow performed within secondary application

3. How can the client application get the user鈥檚 metadata information? authentication-phase-faq3

The client application can query one of the following endpoints capable to return user metadata information as part of the profile information:

• Profiles endpoint API
• Profiles endpoint for specific MVPD API
• Profiles endpoint for specific (authentication) code API

For more details, refer to the following documents:

• Basic profiles flow performed within primary application
• Basic profiles flow performed within secondary application

4. What鈥檚 an authentication session and how long is it valid? authentication-phase-faq4

The authentication session is a term defined in the Glossary documentation.

The authentication session stores information about the initiated authentication process that can be retrieved from the Sessions endpoint.

The authentication session is valid for a limited and short timeframe specified at the moment of issue, indicating the amount of time the user has to complete the authentication process before requiring to restart the flow.

The client application can use the authentication session response to know how to proceed with the authentication process. Take notice that there are cases in which the user is not required to authenticate, such as providing temporary access, degraded access, or when the user is already authenticated.

For more information, refer to the following documents:

• Create authentication session API
• Resume authentication session API
• Basic authentication flow performed within primary application
• Basic authentication flow performed within secondary application

5. What鈥檚 an authentication code and how long is it valid? authentication-phase-faq5

The authentication code is a term defined in the Glossary documentation.

The authentication code stores a unique value generated when a user initiates the authentication process, and uniquely identifies a user鈥檚 authentication session until the process is complete or until the authentication session expires.

The authentication code is valid for a limited and short timeframe specified at the moment of initiating the authentication session, indicating the amount of time the user has to complete the authentication process before requiring to restart the flow.

The client application can use the authentication code to allow the user to complete or resume the authentication process either on the same device or on a second one, considering that the authentication session did not expire.

For more information, refer to the following documents:

• Create authentication session API
• Resume authentication session API
• Basic authentication flow performed within primary application
• Basic authentication flow performed within secondary application

6. How can the client application know if the user typed a valid authentication code and that the authentication session did not expire yet? authentication-phase-faq6

The client application can validate the authentication code that is typed by the user in a secondary (screen) application by sending a request to the Sessions endpoint responsible to retrieve authentication session information associated with the authentication code.

The client application would receive an error if the provided authentication code would be typed wrong or in case the authentication session would be expired.

For more information, refer to the Retrieve authentication session documentation.

7. What鈥檚 a profile and how long is it valid? authentication-phase-faq7

The profile is a term defined in the Glossary documentation.

The profile stores information about the user鈥檚 authentication validity, metadata information and many more that can be retrieved from the Profiles endpoint.

The client application can use the profile to know the user鈥檚 authentication status, access user metadata information or find the method used to authenticate.

For more details, refer to the following documents:

• Profiles endpoint API
• Profiles endpoint for specific MVPD API
• Profiles endpoint for specific (authentication) code API
• Basic profiles flow performed within primary application
• Basic profiles flow performed within secondary application

The profile is valid for a limited timeframe specified when queried, indicating the amount of time the user has a valid authentication before requiring to go through the Authentication Phase again.

This limited timeframe known as authentication (authN) TTL can be viewed and changed through the 51黑料不打烊 Pass TVE Dashboard by one of your organization administrators or by an 51黑料不打烊 Pass Authentication representative acting on your behalf.

For more details, refer to the TVE Dashboard Integrations User Guide documentation.

Preauthorization Phase FAQs

1. What鈥檚 the purpose of the Preauthorization Phase? preauthorization-phase-faq1

The purpose of the Preauthorization Phase is to provide the client application the capability to present a subset of resources from its catalog that the user would be entitled to access.

The Preauthorization Phase can enhance the user experience when the user opens the client application for the first time or navigates to a new section.

2. Is the Preauthorization Phase mandatory? preauthorization-phase-faq2

The Preauthorization Phase is not mandatory, the client application can skip this phase if it wants to present a catalog of resources without filtering them first based on the user鈥檚 entitlement.

3. What鈥檚 a preauthorization decision? preauthorization-phase-faq3

The preauthorization is a term defined in the Glossary documentation, while the decision term can also be found in the Glossary.

The preauthorization decision stores information about the MVPD preauthorization process enquiry result that can be retrieved from the Decisions Preauthorize endpoint.

The client application can use the preauthorization decisions to present a subset of resources the TV Provider (informative) decisions would allow the user to access.

For more details, refer to the following documents:

• Retrieve preauthorization decisions API
• Basic preauthorization flow performed within primary application

4. Why is the preauthorization decision missing a media token? preauthorization-phase-faq4

The preauthorization decision is missing a media token because the Preauthorization Phase must not be used to play resources, as that is the purpose of the Authorization Phase.

5. What is a resource and what formats are supported? preauthorization-phase-faq5

The resource is a term defined in the Glossary documentation.

The resource is a unique identifier that is agreed upon with MVPDs and is associated with a content that the client application could stream.

The resource unique identifier can have two formats:

• A simple string format such as a unique identifier for a channel (brand).
• A media RSS (MRSS) format containing additional information such as the title, ratings and parental-control metadata.

For more details, refer to the Identifying Protected Resources documentation.

6. For how many resources can the client application obtain a preauthorization decision at a time? preauthorization-phase-faq6

The client application can obtain a preauthorization decision for a limited number of resources in a single API request, usually up to 5, due to conditions imposed by MVPDs.

This maximum number of resources can be viewed and changed after agreeing with MVPDs through the 51黑料不打烊 Pass TVE Dashboard by one of your organization administrators or by an 51黑料不打烊 Pass Authentication representative acting on your behalf.

For more details, refer to the TVE Dashboard Integrations User Guide documentation.

Authorization Phase FAQs

1. What鈥檚 the purpose of the Authorization Phase? authorization-phase-faq1

The purpose of the Authorization Phase is to provide the client application the capability to play resources the user requests after validating their rights with the MVPD.

2. Is the Authorization Phase mandatory? authorization-phase-faq2

The Authorization Phase is mandatory, the client application cannot skip this phase if it wants to play resources the user requests, as it requires verifying with the MVPD that the user is entitled before releasing the stream.

3. What鈥檚 an authorization decision and how long is it valid? authorization-phase-faq3

The authorization is a term defined in the Glossary documentation, while the decision term can also be found in the Glossary.

The authorization decision stores information about the MVPD authorization process enquiry result that can be retrieved from the Decisions Authorize endpoint.

The client application can use the authorization decision containing a media token to play the resource stream in case the TV Provider (authoritative) decision would allow the user to access it.

For more details, refer to the following documents:

• Retrieve authorization decisions API
• Basic authorization flow performed within primary application

The authorization decision is valid for a limited and short timeframe specified at the moment of issue, indicating the amount of time it will be cached by 51黑料不打烊 Pass Authentication before requiring to query the MVPD again.

This limited timeframe known as authorization (authZ) TTL can be viewed and changed through the 51黑料不打烊 Pass TVE Dashboard by one of your organization administrators or by an 51黑料不打烊 Pass Authentication representative acting on your behalf.

For more details, refer to the TVE Dashboard Integrations User Guide documentation.

4. What鈥檚 a media token and how long is it valid? authorization-phase-faq4

The media token is a term defined in the Glossary documentation.

The media token consists of a signed string sent in clear text that can be retrieved from the Decisions Authorize endpoint.

For more information, refer to the Integrating the Media Token Verifier documentation.

The media token is valid for a limited and short timeframe specified at the moment of issue, indicating the amount of time it must be used by the client application before requiring to query the Decisions Authorize endpoint again.

The client application can use the media token to play a resource stream in case the TV Provider (authoritative) decision would allow the user to access it.

For more details, refer to the following documents:

• Retrieve authorization decisions API
• Basic authorization flow performed within primary application

5. What is a resource and what formats are supported? authorization-phase-faq5

The resource is a term defined in the Glossary documentation.

The resource is a unique identifier that is agreed upon with MVPDs and is associated with a content that the client application could stream.

The resource unique identifier can have two formats:

• A simple string format such as a unique identifier for a channel (brand).
• A media RSS (MRSS) format containing additional information such as the title, ratings and parental-control metadata.

For more details, refer to the Identifying Protected Resources documentation.

6. For how many resources can the client application obtain an authorization decision at a time? authorization-phase-faq6

The client application can obtain an authorization decision for a limited number of resources in a single API request, usually up to 1, due to conditions imposed by MVPDs.

Logout Phase FAQs

1. What鈥檚 the purpose of the Logout Phase? logout-phase-faq1

The purpose of the Logout Phase is to provide the client application the capability to terminate the user鈥檚 authenticated profile within 51黑料不打烊 Pass Authentication upon user request.

Headers FAQs

1. How to compute the value for the Authorization header? headers-faq1

The Authorization request header contains the Bearer access token required by the client application to access 51黑料不打烊 Pass protected APIs.

The Authorization header value must be obtained from 51黑料不打烊 Pass Authentication during the Registration Phase.

For more details, refer to the following documents:

• Dynamic Client Registration Overview
• Retrieve client credentials API
• Retrieve access token API
• Dynamic Client Registration Flow

In case the client application is migrating from REST API V1 to REST API V2, the client application can continue to use the same method to obtain the Bearer access token as before.

2. How to compute the value for the AP-Device-Identifier header? headers-faq2

The AP-Device-Identifier request header contains the streaming device identifier as it was created by the client application.

The AP-Device-Identifier header documentation provides some examples of how to compute the value for different platforms, but the client application can choose to use a different method based on its own business logic and requirements.

In case the client application is migrating from REST API V1 to REST API V2, the client application can continue to use the same method to compute the device identifier as before.

3. How to compute the value for the X-Device-Info header? headers-faq3

The X-Device-Info request header contains the client information (device, connection and application) related to the actual streaming device.

The X-Device-Info header documentation provides some examples of how to compute the value for different platforms, but the client application can choose to use a different method based on its own business logic and requirements.

In case the client application is migrating from REST API V1 to REST API V2, the client application can continue to use the same method to compute the device information as before.

General Migration FAQs

1. Am I required to roll out a new client application migrated to REST API V2 to all users at once? migration-faq1

No.

The client application is not required to roll out a new version integrating the REST API V2 to all users simultaneously.

51黑料不打烊 Pass Authentication will continue to support older client application versions integrating the REST API V1 or SDK through the end of 2025.

2. Am I required to roll out a new client application migrated to REST API V2 across all APIs and flows at once? migration-faq2

Yes.

The client application is required to roll out a new version integrating the REST API V2 across all 51黑料不打烊 Pass Authentication APIs and flows simultaneously.

In case of the 鈥榮econd screen authentication鈥� flow, the client application is required to roll out a new version integrating the REST API V2 for both the primary and secondary applications simultaneously.

51黑料不打烊 Pass Authentication will not support 鈥榟ybrid鈥� implementations that integrate both REST API V2 and REST API V1/SDK between APIs and flows.

3. Will the user authentication be preserved when updating to a new client application migrated to REST API V2? migration-faq3

No.

The user authentication obtained within older client application versions integrating the REST API V1 or SDK will not be preserved.

Therefore, the user will be required to re-authenticate within the new client application migrated to REST API V2.

4. Can the client application use the existing registered applications (software statements)? migration-faq4

The client application cannot re-use the existing registered applications (software statements), therefore it must generate and download a new registered applications (software statements) dedicated for consuming REST API V2.

This operation can be completed through the 51黑料不打烊 Pass TVE Dashboard by one of your organization administrators or by an 51黑料不打烊 Pass Authentication representative acting on your behalf.

For more details, refer to the TVE Dashboard Channels User Guide or TVE Dashboard Programmers User Guide documentation.

For the moment you will be required to ask an 51黑料不打烊 Pass Authentication representative to enable the usage of REST API V2 for your new registered applications (software statements), until the 51黑料不打烊 Pass TVE Dashboard will be updated to allow the self-management of this operation.

In order to distinguish the registered applications (software statements) used in client applications consuming REST API V2, we require you to add a specific suffix to the registered application name, such as 鈥淩ESTV2鈥�.

5. Can the client application use the existing custom schemes? migration-faq5

The client application can re-use the existing custom schemes generated through the 51黑料不打烊 Pass TVE Dashboard.

For more details, refer to the TVE Dashboard Channels User Guide or TVE Dashboard Programmers User Guide documentation.

6. Are the enhanced error codes enabled by default in REST API V2? migration-faq6

Yes.

The client applications integrating REST API V2 benefit from the enhanced error codes feature enabled by default.

For more details, refer to the Enhanced Error Codes documentation.

Registration Phase FAQs

1. What are the high-level API migrations required for the Registration Phase? registration-phase-v1-to-v2-faq1

In the migration from REST API V1 to REST API V2 there are no high level changes in regard to the Registration Phase.

The client application can continue to use the same flow to register against 51黑料不打烊 Pass Authentication through the Dynamic Client Registration (DCR) process and obtain an access token.

For more information, refer to the following documents:

• Dynamic Client Registration Overview
• Retrieve client credentials API
• Retrieve access token API
• Dynamic Client Registration Flow

Configuration Phase FAQs

1. What are the high-level API migrations required for the Configuration Phase? configuration-phase-v1-to-v2-faq1

In the migration from REST API V1 to REST API V2 there are high level changes to consider that are presented in the following table:

table 0-row-4 1-row-4
Scope	REST API V1	REST API V2	Observations
Retrieve list of MVPDs with active integration	GET /api/v1/config/{serviceProvider}	GET /api/v2/{serviceProvider}/configuration

Authentication Phase FAQs

1. What are the high-level API migrations required for the Authentication Phase? authentication-phase-v1-to-v2-faq1

In the migration from REST API V1 to REST API V2 there are high level changes to consider that are presented in the following table:

table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 7-row-4
Scope	REST API V1	REST API V2	Observations
Retrieve registration code (authentication code)	POST /reggie/v1/{serviceProvider}/regcode	POST /api/v2/{serviceProvider}/sessions	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check registration code (authentication code)	GET /reggie/v1/{serviceProvider}/regcode/{code}	GET /api/v2/{serviceProvider}/sessions/{code}	For more details, refer to the following documents: Basic authentication flow performed within secondary application
Resume (MVPD) authentication on second screen (application)	GET /api/v1/authenticate	POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within secondary application
Initiate (MVPD) authentication	GET /api/v1/authenticate	GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check user authentication status	GET /api/v1/checkauthn (first screen) GET /api/v1/checkauthn (second screen)	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application
Retrieve user authentication token (profile)	GET /api/v1/tokens/authn	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application
Retrieve user metadata information	GET /api/v1/tokens/usermetadata	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application

Preauthorization Phase FAQs

1. What are the high-level API migrations required for the Preauthorization Phase? preauthorization-phase-v1-to-v2-faq1

In the migration from REST API V1 to REST API V2 there are high level changes to consider that are presented in the following table:

table 0-row-4 1-row-4
Scope	REST API V1	REST API V2	Observations
Retrieve preauthorized resources (preauthorization decisions)	GET /api/v1/preauthorize (first screen) GET /api/v1/preauthorize (second screen)	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	For more details, refer to the following documents: Basic preauthorization flow performed within primary application

Authorization Phase FAQs

1. What are the high-level API migrations required for the Authorization Phase? authorization-phase-v1-to-v2-faq1

In the migration from REST API V1 to REST API V2 there are high level changes to consider that are presented in the following table:

table 0-row-4 1-row-4 2-row-4 3-row-4
Scope	REST API V1	REST API V2	Observations
Initiate (MVPD) authorization	GET /api/v1/authorize	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	The client application can use the response of this API for multiple purposes at once: Initiate (MVPD) authorization Retrieve authorization decision Retrieve short media token For more details, refer to the following documents: Basic authorization flow performed within primary application
Retrieve authorization token (authorization decision)	GET /api/v1/tokens/authz	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	The client application can use the response of this API for multiple purposes at once: Initiate (MVPD) authorization Retrieve authorization decision Retrieve short media token For more details, refer to the following documents: Basic authorization flow performed within primary application
Retrieve short authorization token (media token)	GET /api/v1/tokens/media	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	The client application can use the response of this API for multiple purposes at once: Initiate (MVPD) authorization Retrieve authorization decision Retrieve short media token For more details, refer to the following documents: Basic authorization flow performed within primary application

Logout Phase FAQs

1. What are the high-level API migrations required for the Logout Phase? logout-phase-v1-to-v2-faq1

In the migration from REST API V1 to REST API V2 there are high level changes to consider that are presented in the following table:

table 0-row-4 1-row-4
Scope	REST API V1	REST API V2	Observations
Initiate logout	GET /api/v1/logout	GET /api/v2/{serviceProvider}/logout	For more details, refer to the following documents: Basic logout flow performed within primary application

Registration Phase FAQs

1. What are the high-level API migrations required for the Registration Phase? registration-phase-sdk-to-v2-faq1

In the migration from SDKs to REST API V2 there are high level changes to consider that are presented in the following tables:

AccessEnabler JavaScript SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Complete Dynamic Client Registration (DCR)	Providing software statement to constructor	POST /o/client/register GET /o/client/token	For more details, refer to the following documents: Dynamic Client Registration Overview Dynamic Client Registration Flow

AccessEnabler iOS/tvOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Complete Dynamic Client Registration (DCR)	Providing software statement to constructor	POST /o/client/register GET /o/client/token	For more details, refer to the following documents: Dynamic Client Registration Overview Dynamic Client Registration Flow

AccessEnabler Android SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Complete Dynamic Client Registration (DCR)	Providing software statement to constructor	POST /o/client/register GET /o/client/token	For more details, refer to the following documents: Dynamic Client Registration Overview Dynamic Client Registration Flow

AccessEnabler FireOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Complete Dynamic Client Registration (DCR)	Providing software statement to constructor	POST /o/client/register GET /o/client/token	For more details, refer to the following documents: Dynamic Client Registration Overview Dynamic Client Registration Flow

Configuration Phase FAQs

1. What are the high-level API migrations required for the Configuration Phase? configuration-phase-sdk-to-v2-faq1

In the migration from SDKs to REST API V2 there are high level changes to consider that are presented in the following tables:

AccessEnabler JavaScript SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve list of MVPDs with active integration	AccessEnabler.getAuthentication	GET /api/v2/{serviceProvider}/configuration

AccessEnabler iOS/tvOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve list of MVPDs with active integration	AccessEnabler.getAuthentication	GET /api/v2/{serviceProvider}/configuration

AccessEnabler Android SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve list of MVPDs with active integration	AccessEnabler.getAuthentication	GET /api/v2/{serviceProvider}/configuration

AccessEnabler FireOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve list of MVPDs with active integration	AccessEnabler.getAuthentication	GET /api/v2/{serviceProvider}/configuration

Authentication Phase FAQs

1. What are the high-level API migrations required for the Authentication Phase? authentication-phase-sdk-to-v2-faq1

In the migration from SDKs to REST API V2 there are high level changes to consider that are presented in the following tables:

AccessEnabler JavaScript SDK

table 0-row-4 1-row-4 2-row-4 3-row-4
Scope	SDK	REST API V2	Observations
Initiate (MVPD) authentication	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check user authentication status	AccessEnabler.checkAuthentication	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application
Retrieve user metadata information	AccessEnabler.getMetadata	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application

AccessEnabler iOS SDK

table 0-row-4 1-row-4 2-row-4 3-row-4
Scope	SDK	REST API V2	Observations
Initiate (MVPD) authentication	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check user authentication status	AccessEnabler.checkAuthentication	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application
Retrieve user metadata information	AccessEnabler.getMetadata	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application

AccessEnabler tvOS SDK

table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4
Scope	SDK	REST API V2	Observations
Retrieve registration code (authentication code)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check registration code (authentication code)	GET /reggie/v1/{serviceProvider}/regcode/{code}	GET /api/v2/{serviceProvider}/sessions/{code}	For more details, refer to the following documents: Basic authentication flow performed within secondary application
Resume (MVPD) authentication on second screen (application)	GET /api/v1/authenticate	POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within secondary application
Initiate (MVPD) authentication	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check user authentication status	AccessEnabler.checkAuthentication	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application
Retrieve user metadata information	AccessEnabler.getMetadata	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application

AccessEnabler Android SDK

table 0-row-4 1-row-4 2-row-4 3-row-4
Scope	SDK	REST API V2	Observations
Initiate (MVPD) authentication	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check user authentication status	AccessEnabler.checkAuthentication	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application
Retrieve user metadata information	AccessEnabler.getMetadata	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application

AccessEnabler FireOS SDK

table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4
Scope	SDK	REST API V2	Observations
Retrieve registration code (authentication code)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check registration code (authentication code)	GET /reggie/v1/{serviceProvider}/regcode/{code}	GET /api/v2/{serviceProvider}/sessions/{code}	For more details, refer to the following documents: Basic authentication flow performed within secondary application
Resume (MVPD) authentication on second screen (application)	GET /api/v1/authenticate	POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within secondary application
Initiate (MVPD) authentication	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	For more details, refer to the following documents: Basic authentication flow performed within primary application Basic authentication flow performed within secondary application
Check user authentication status	AccessEnabler.checkAuthentication	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application
Retrieve user metadata information	AccessEnabler.getMetadata	Use one of the following: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	The client application can use the response of these APIs for multiple purposes at once: Check user authentication status Retrieve user profile Retrieve user metadata information For more details, refer to the following documents: Basic profiles flow performed within primary application Basic profiles flow performed within secondary application

Preauthorization Phase FAQs

1. What are the high-level API migrations required for the Preauthorization Phase? preauthorization-phase-sdk-to-v2-faq1

In the migration from SDKs to REST API V2 there are high level changes to consider that are presented in the following tables:

AccessEnabler JavaScript SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve preauthorized resources (preauthorization decisions)	AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	For more details, refer to the following documents: Basic preauthorization flow performed within primary application

AccessEnabler iOS/tvOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve preauthorized resources (preauthorization decisions)	AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	For more details, refer to the following documents: Basic preauthorization flow performed within primary application

AccessEnabler Android SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve preauthorized resources (preauthorization decisions)	AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	For more details, refer to the following documents: Basic preauthorization flow performed within primary application

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve preauthorized resources (preauthorization decisions)	AccessEnabler.checkPreauthorizedResources	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	For more details, refer to the following documents: Basic preauthorization flow performed within primary application

Authorization Phase FAQs

1. What are the high-level API migrations required for the Authorization Phase? authorization-phase-sdk-to-v2-faq1

In the migration from SDKs to REST API V2 there are high level changes to consider that are presented in the following tables:

AccessEnabler JavaScript SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve short authorization token (media token)	AccessEnabler.checkAuthorization AccessEnabler.getAuthorization	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	The client application can use the response of this API for multiple purposes at once: Initiate (MVPD) authorization Retrieve authorization decision Retrieve short media token For more details, refer to the following documents: Basic authorization flow performed within primary application

AccessEnabler iOS/tvOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve short authorization token (media token)	AccessEnabler.checkAuthorization AccessEnabler.getAuthorization	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	The client application can use the response of this API for multiple purposes at once: Initiate (MVPD) authorization Retrieve authorization decision Retrieve short media token For more details, refer to the following documents: Basic authorization flow performed within primary application

AccessEnabler Android SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve short authorization token (media token)	AccessEnabler.checkAuthorization AccessEnabler.getAuthorization	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	The client application can use the response of this API for multiple purposes at once: Initiate (MVPD) authorization Retrieve authorization decision Retrieve short media token For more details, refer to the following documents: Basic authorization flow performed within primary application

AccessEnabler FireOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Retrieve short authorization token (media token)	AccessEnabler.checkAuthorization AccessEnabler.getAuthorization	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	The client application can use the response of this API for multiple purposes at once: Initiate (MVPD) authorization Retrieve authorization decision Retrieve short media token For more details, refer to the following documents: Basic authorization flow performed within primary application

Logout Phase FAQs

1. What are the high-level API migrations required for the Logout Phase? logout-phase-sdk-to-v2-faq1

In the migration from SDKs to REST API V2 there are high level changes to consider that are presented in the following tables:

AccessEnabler JavaScript SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Initiate logout	AccessEnabler.logout	GET /api/v2/{serviceProvider}/logout	For more details, refer to the following documents: Basic logout flow performed within primary application

AccessEnabler iOS/tvOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Initiate logout	AccessEnabler.logout	GET /api/v2/{serviceProvider}/logout	For more details, refer to the following documents: Basic logout flow performed within primary application

AccessEnabler Android SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Initiate logout	AccessEnabler.logout	GET /api/v2/{serviceProvider}/logout	For more details, refer to the following documents: Basic logout flow performed within primary application

AccessEnabler FireOS SDK

table 0-row-4 1-row-4
Scope	SDK	REST API V2	Observations
Initiate logout	AccessEnabler.logout	GET /api/v2/{serviceProvider}/logout	For more details, refer to the following documents: Basic logout flow performed within primary application