51ºÚÁϲ»´òìÈ

Registration Phase FAQs

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

Configuration Phase FAQs

1. What’s 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 (e.g., id, displayName, logoUrl, etc.) 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 must retrieve the configuration only when the user needs to select their MVPD to authenticate or re-authenticate.

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’s a configuration and how long is it valid? configuration-phase-faq3

The configuration is a term defined in the Glossary documentation.

The configuration contains a list of MVPDs defined by the following attributes id, displayName, logoUrl, etc., that can be retrieved from the Configuration endpoint.

The client application must retrieve the configuration only when the user needs to select their MVPD to authenticate or re-authenticate.

The client application can use the configuration response to present a UI picker with available MVPD options whenever the user needs to select their TV provider.

The client application must store the user’s selected MVPD identifier, as specified by the MVPD’s configuration-level id attribute, to proceed with the Authentication, Preauthorization, Authorization, or Logout phases.

For more information, refer to the Retrieve configuration documentation.

4. Should the client application cache the configuration response information in a persistent storage? configuration-phase-faq4

The client application must retrieve the configuration only when the user needs to select their MVPD to authenticate or re-authenticate.

The client application should cache the configuration response information in a memory storage to avoid unnecessary requests and improve the user experience when:

• 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.

5. Can the client application manage its own list of MVPDs? configuration-phase-faq5

The client application can manage its own list of MVPDs, but it would require to keep the MVPD identifiers in sync with 51ºÚÁϲ»´òìÈ Pass Authentication. Therefore, 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 provided MVPD identifier is invalid or in case it does not have an active integration with the specified service provider.

6. Can the client application filter the list of MVPDs? configuration-phase-faq6

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

The client application can filter the list of TempPass MVPDs or the MVPDs that have their integration still in development or testing.

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

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.

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

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.

9. How to enable or disable the integration with an MVPD? configuration-phase-faq9

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’s 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’s 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. Is the Authentication Phase mandatory? authentication-phase-faq2

The Authentication Phase is mandatory, the client application must authenticate the user when it does not have a valid profile within 51ºÚÁϲ»´òìÈ Pass Authentication.

The client application can skip this phase in the following scenarios:

• The user is already authenticated and the profile is still valid.
• The user is offered temporary access through basic or promotional TempPass feature.

The client application error handling requires to handle the error codes (e.g., authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated, etc.), which indicate that the client application requires the user to authenticate.

3. What’s an authentication session and how long is it valid? authentication-phase-faq3

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 by the notAfter timestamp, 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

4. What’s an authentication code and how long is it valid? authentication-phase-faq4

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’s 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 by the notAfter timestamp, 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 verify whether the user has successfully completed authentication and retrieve the user’s profile information, typically through a polling mechanism.

The client application can also use the authentication code to allow the user to complete or resume the authentication process either on the same device or on a second (screen) 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

5. 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-faq5

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

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

For more information, refer to the Resume authentication session and Retrieve authentication session documents.

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

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

7. What’s 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’s 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’s authentication status, access user metadata information, find the method used to authenticate or the entity used to provide identity.

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 by the notAfter timestamp, 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.

8. Should the client application cache the user’s profile information in a persistent storage? authentication-phase-faq8

The client application should cache parts of the user’s profile information in a persistent storage to avoid unnecessary requests and improve the user experience considering the following aspects:

table 0-row-2 1-row-2 2-row-2 3-row-2
Attribute	User Experience
mvpd	The client application can use this to keep track of the user’s selected TV provider and continue to use it further during Preauthorization or Authorization Phases. When the current user profile expires, the client application can use the remembered MVPD selection and just ask the user to confirm.
attributes	The client application can use this to personalize the user experience based on different user metadata keys (e.g., zip, maxRating, etc.). User metadata becomes available after the authentication flow completes, therefore the client application does not need to query a separate endpoint to retrieve the user metadata information, as it is already included in the profile information. Certain metadata attributes may be updated during the authorization flow, depending on the MVPD and the specific metadata attribute. As a result, the client application may need to query the Profiles APIs again to retrieve the latest user metadata.
notAfter	The client application can use this to keep track of user profile expiration date. The client application error handling requires to handle the error codes (e.g., authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated, etc.), which indicates that the client application requires the user to authenticate.

9. Can the client application extend the user’s profile without requiring re-authentication? authentication-phase-faq9

No.

The user profile cannot be extended beyond its validity without user interaction, as its expiration is determined by the authentication TTL established with MVPDs.

Therefore, the client application must prompt the user to re-authenticate and interact with the MVPD login page to refresh their profile on our system.

However, for MVPDs that support home-based authentication (HBA), the user will not be required to enter credentials.

10. What are the use cases for each available Profiles endpoint? authentication-phase-faq10

The basic Profiles endpoints are designed to provide client application the capability to know the user’s authentication status, access user metadata information, find the method used to authenticate or the entity used to provide identity.

Each endpoint suits a specific use case, as follows:

table 0-row-3 1-row-3 2-row-3 3-row-3
API	Description	Use case
Profiles endpoint API	Retrieve all user profiles.	User opens the client application for the first time In this scenario, the client application does not have the user’s selected MVPD identifier cached in persistent storage. As a result, it will send a single request to retrieve all available user profiles.
Profiles endpoint for specific MVPD API	Retrieve the user profile associated with a specific MVPD.	User returns to the client application after authenticating in a previous visit In this case, the client application must have the user’s previously selected MVPD identifier cached in persistent storage. As a result, it will send a single request to retrieve the user’s profile for that specific MVPD.
Profiles endpoint for specific (authentication) code API	Retrieve the user profile associated with a specific authentication code.	User initiates the authentication process In this scenario, the client application must determine whether the user has successfully completed authentication and retrieve their profile information. As a result, it will start a polling mechanism to retrieve the user’s profile associated with the authentication code.

For more details, refer to the Basic profiles flow performed within primary application and Basic profiles flow performed within secondary application documents.

The Profiles SSO endpoint serves a different purpose, it provides the client application the capability to create a user profile using the partner authentication response and retrieve it in a single, one-time operation.

table 0-row-3 1-row-3
API	Description	Use case
Profiles SSO endpoint API	Create and retrieve user profile using partner authentication response.	User permits the application to use partner single-sign-on to authenticate In this scenario, the client application must create a user profile after receiving the partner authentication response and retrieve it in a single, one-time operation.

For any subsequent queries, the basic Profiles endpoints must be used to determine the user’s authentication status, access user metadata information, find the method used to authenticate or the entity used to provide identity.

For more details, refer to the Single sign-on using partner flows and Apple SSO Cookbook (REST API V2) documents.

11. What should the client application do if the user has multiple MVPD profiles? authentication-phase-faq11

The decision to support multiple profiles depends on the client application’s business requirements.

Most users will have only one profile. However, in cases where multiple profiles exist (as detailed below), the client application is responsible for determining the best user experience for profile selection.

The client application may choose to prompt the user to select the desired MVPD profile or make the selection automatically, such as choosing the first user profile from the response or the one with the longest validity period.

REST API v2 supports multiple profiles to accommodate:

• Users who may have to choose between a regular MVPD profile and one obtained via single sign-on (SSO).
• Users being offered temporary access without requiring to log out from their regular MVPD.
• Users with MVPD subscription combined with Direct-to-Consumer (DTC) services.
• Users with multiple MVPD subscriptions.

12. What happens when user profiles expire? authentication-phase-faq12

When user profiles expire, they are no longer included in the response from the Profiles endpoint.

If the Profiles endpoint returns an empty profiles map response, the client application must create a new authentication session and prompt the user to re-authenticate.

For more information, refer to the Create authentication session API documentation.

13. When do user profiles become invalid? authentication-phase-faq13

User profiles become invalid in the following scenarios:

• When the authentication TTL expires, as indicated by the notAfter timestamp in the Profiles endpoint response.
• When the client application changes the AP-Device-Identifier header value.
• When the client application updates the client credentials used to retrieve the Authorization header value.
• When the client application revokes or updates the software statement used to obtain client credentials.

14. When should the client application start the polling mechanism? authentication-phase-faq14

To ensure efficiency and avoid unnecessary requests, the client application must start the polling mechanism under the following conditions:

Authentication performed within the primary (screen) application

The primary (streaming) application should start polling when the user reaches the final destination page, after the browser component loads the URL specified for the redirectUrl parameter in the Sessions endpoint request.

Authentication performed within a secondary (screen) application

The primary (streaming) application should start polling as soon as the user initiates the authentication process—right after receiving the Sessions endpoint response and displaying the authentication code to the user.

15. When should the client application stop the polling mechanism? authentication-phase-faq15

To ensure efficiency and avoid unnecessary requests, the client application must stop the polling mechanism under the following conditions:

Successful authentication

The user’s profile information is successfully retrieved, confirming their authentication status. At this point, polling is no longer needed.

Authentication session and code expiry

The authentication session and code expire, as indicated by the notAfter timestamp (e.g., 30 minutes) in the Sessions endpoint response. If this happens, the user must restart the authentication process, and polling using the previous authentication code should be stopped immediately.

New authentication code generated

If the user requests a new authentication code on the primary (screen) device, the existing session is no longer valid, and polling using the previous authentication code should be stopped immediately.

16. What interval between calls should the client application use for the polling mechanism? authentication-phase-faq16

To ensure efficiency and avoid unnecessary requests, the client application must configure the polling mechanism frequency under the following conditions:

table 0-row-2 1-row-2
Authentication performed within the primary (screen) application	Authentication performed within a secondary (screen) application
The primary (streaming) application should poll every 3-5 seconds or more.	The primary (streaming) application should poll every 3-5 seconds or more.

17. What’s the maximum number of polling requests the client application can send? authentication-phase-faq17

The client application must adhere to the current limits defined by the 51ºÚÁϲ»´òìÈ Pass Authentication Throttling Mechanism.

The client application error handling must be able to handle the 429 Too Many Requests error code, which indicates that the client application has exceeded the maximum number of requests allowed.

For more details, refer to the Throttling Mechanism documentation.

18. How can the client application get the user’s metadata information? authentication-phase-faq18

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

User metadata becomes available after the authentication flow completes, therefore the client application does not need to query a separate endpoint to retrieve the user metadata information, as it is already included in the profile information.

For more details, refer to the following documents:

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

Certain metadata attributes may be updated during the authorization flow, depending on the MVPD and the specific metadata attribute. As a result, the client application may need to query the above APIs again to retrieve the latest user metadata.

19. How should the client application manage degraded access? authentication-phase-faq19

The Degradation Feature enables the client application to maintain a seamless streaming experience for users, even when their MVPD’s authentication or authorization services encounter issues.

As a summary, this can ensure uninterrupted access to content despite MVPD temporary service disruptions.

Given that your organization intends to use the premium degradation feature, the client application must handle degraded access flows, which outline how REST API v2 endpoints behave in such scenarios.

For more details, refer to the Degraded access flows documentation.

20. How should the client application manage temporary access? authentication-phase-faq20

The TempPass Feature enables the client application to provide temporary access to the user.

As a summary, this can engage users by providing time-limited access to content or a predefined number of VOD titles for a specified time period.

Given that your organization intends to use the premium TempPass feature, the client application must handle temporary access flows, which outline how REST API v2 endpoints behave in such scenarios.

In previous API versions, the client application had to log out a user authenticated with their regular MVPD to offer temporary access.

With REST API v2, the client application can seamlessly switch between a regular MVPD and a TempPass MVPD when authorizing a stream, eliminating the need for the user to be logged out.

For more details, refer to the Temporary access flows documentation.

21. How should the client application manage cross-device single sign-on access? authentication-phase-faq21

REST API v2 can enable cross-device single sign-on if the client application provides a consistent unique user identifier across devices.

This identifier, known as a service token, must be generated by the client application through the implementation or integration of an external Identity Service of choice.

For more details, refer to the Single sign-on using service token flows documentation.

Preauthorization Phase FAQs

1. What’s 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’s entitlement.

3. What’s 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. Should the client application cache the preauthorization decisions in a persistent storage? preauthorization-phase-faq4

The client application is not required to store preauthorization decisions in persistent storage. However, it is recommended to cache permit decisions in memory to improve the user experience. This helps avoid unnecessary calls to the Decisions Preauthorize endpoint for resources that have already been preauthorized, reducing latency and improving performance.

5. How can the client application determine why a preauthorization decision was denied? preauthorization-phase-faq5

The client application can determine the reason for a denied preauthorization decision by inspecting the error code and message included in the response from the Decisions Preauthorize endpoint. These details provide insight into the specific reason the preauthorization request was denied, helping to inform the user experience or trigger any necessary handling in the application.

Ensure that any retry mechanism implemented for retrieving preauthorization decisions does not result in an endless loop if the preauthorization decision is denied.

Consider limiting retries to a reasonable number and handling denials gracefully by surfacing clear feedback to the user.

6. Why is the preauthorization decision missing a media token? preauthorization-phase-faq6

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.

7. Can the Authorization Phase be skipped if a preauthorization decision already exists? preauthorization-phase-faq7

No.

The Authorization Phase cannot be skipped even if a preauthorization decision is available. Preauthorization decisions are informational only and do not grant actual playback rights. The Preauthorization Phase is intended to provide early guidance, but the Authorization Phase is still required before playing any content.

8. What is a resource and what formats are supported? preauthorization-phase-faq8

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 Protected Resources documentation.

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

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’s 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’s 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. Should the client application cache the authorization decisions in a persistent storage? authorization-phase-faq4

The client application is not required to store authorization decisions in persistent storage.

5. How can the client application determine why an authorization decision was denied? authorization-phase-faq5

The client application can determine the reason for a denied authorization decision by inspecting the error code and message included in the response from the Decisions Authorize endpoint. These details provide insight into the specific reason the authorization request was denied, helping to inform the user experience or trigger any necessary handling in the application.

Ensure that any retry mechanism implemented for retrieving authorization decisions does not result in an endless loop if the authorization decision is denied.

Consider limiting retries to a reasonable number and handling denials gracefully by surfacing clear feedback to the user.

6. What’s a media token and how long is it valid? authorization-phase-faq6

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 Media Token Verifier documentation.

The media token is valid for a limited and short timeframe specified at the moment of issue, indicating the time limit before it must be verified and used by the client application.

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

7. Should the client application validate the media token before playing the resource stream? authorization-phase-faq7

Yes.

The client application must validate the media token before starting playback of the resource stream. This validation should be performed using the Media Token Verifier. By verifying the serializedToken from the returned token, the client application helps prevent unauthorized access, such as stream ripping, and ensures that only properly authorized users can play the content.

8. Should the client application refresh an expired media token during playback? authorization-phase-faq8

No.

The client application is not required to refresh an expired media token while the stream is actively playing. If the media token expires during playback, the stream should be allowed to continue uninterrupted. However, the client must request a new authorization decision — and obtain a new media token — the next time the user attempts to play a resource.

9. What is the purpose of each timestamp attribute in the authorization decision? authorization-phase-faq9

The authorization decision includes several timestamp attributes that provide essential context about the validity period of the authorization itself and the associated media token. These timestamps serve different purposes, depending on whether they relate to the authorization decision or the media token.

Decision-Level Timestamps

These timestamps describe the validity period of the overall authorization decision:

table 0-row-3 1-row-3 2-row-3
Attribute	Description	Notes
notBefore	The time when the authorization decision was issued.	This marks the start of the authorization validity window.
notAfter	The time when the authorization decision expires.	The authorization Time-to-Live (TTL) determines how long the authorization remains valid before requiring re-authorization. This TTL is negotiated with MVPD representatives.

Token-Level Timestamps

These timestamps describe the validity period of the media token that is tied to the authorization decision:

table 0-row-3 1-row-3 2-row-3
Attribute	Description	Notes
notBefore	The time when the media token was issued.	This marks when the token becomes valid for playback.
notAfter	The time when the media token expires.	Media tokens have a deliberately short lifespan (typically 7 minutes) to minimize misuse risks and account for potential clock differences between the token-generating server and the token-verifying server.

10. What is a resource and what formats are supported? authorization-phase-faq10

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 Protected Resources documentation.

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

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’s 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’s authenticated profile within 51ºÚÁϲ»´òìÈ Pass Authentication upon user request.

2. Is the Logout Phase mandatory? logout-phase-faq2

The Logout Phase is mandatory, the client application must provide the user with the capability to log out.

Headers FAQs

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

note important
IMPORTANT
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 value as before.

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

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

note important
IMPORTANT
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 value as before.

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 examples for major platforms of how to compute the value, but the client application can choose to use a different method based on its own business logic and requirements.

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

note important
IMPORTANT
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 value as before.

The X-Device-Info request header contains the client information (device, connection and application) related to the actual streaming device and is used to determine platform-specific rules that MVPDs may enforce.

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

If the X-Device-Info header is missing or contains incorrect values, the request may be classified as originating from an unknown platform.

This can lead to the request being treated as insecure, and subject to more restrictive rules, such as shorter authentication TTLs. Additionally, some fields, such as the streaming device connectionIp and connectionPort, are mandatory for features like Spectrum’s Home Base Authentication.

Even when the request originates from a server on behalf of a device, the X-Device-Info header value must reflect the actual streaming device information.

Misc FAQs

1. Can I explore REST API V2 requests and responses and test the API? misc-faq1

Yes.

You can explore REST API V2 through our dedicated website. The 51ºÚÁϲ»´òìÈ Developer website provides unrestricted access to:

To interact with , you must include the Authorization header with a Bearer access token obtained via the .

For using the , a software statement with REST API V2 scope is required. For more details, refer to the Dynamic Client Registration (DCR) FAQs document.

2. Can I explore REST API V2 requests and responses using an API development tool with OpenAPI support? misc-faq2

Yes.

You can download OpenAPI specification files for the and from the website.

To download the OpenAPI specification files, click the download buttons to save the following files to your local machine:

You can then import these files into your preferred API development tool to explore REST API V2 requests and responses and test the API.

3. Can I still use the existing API test tool hosted at https://sp.auth-staging.adobe.com/apitest/api.html? misc-faq3

No.

The client applications migrating to REST API V2 should use the new test tool hosted at https://developer.adobe.com/adobe-pass/. The 51ºÚÁϲ»´òìÈ Developer website provides unrestricted access to:

To interact with , you must include the Authorization header with a Bearer access token obtained via the .

For using the , a software statement with REST API V2 scope is required. For more details, refer to the Dynamic Client Registration (DCR) FAQs document.

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 ‘second 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 ‘hybrid’ 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. Are the enhanced error codes enabled by default in REST API V2? migration-faq4

Yes.

The client applications migrating to REST API V2 automatically benefit from this feature by default, providing more detailed and precise error information.

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

5. Do existing integrations require configuration changes when migrating to REST API V2? migration-faq5

No.

The client applications migrating to REST API V2 do not require any configuration changes for existing MVPD integrations. Also, they will continue to use the same identifiers for existing service providers and MVPDs.

Additionally, the protocols used by 51ºÚÁϲ»´òìÈ Pass Authentication to communicate with MVPD endpoints remain unchanged.

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