DocumentationAdobe PassAdobe Pass Authentication

REST API V2 FAQs rest-api-v2-faqs

Last update: Fri Dec 06 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
IMPORTANT
The content on this page is provided for information purposes only. Usage of this API requires a current license from Adobe. No unauthorized use is permitted.

This document provides high overview answers for frequently asked questions about the Adobe Pass Authentication REST API V2 adoption.

For more information about the REST API V2 overall, see the REST API V2 Overview documentation.

General FAQs general-faqs

Start with this section if you are working on an application that needs to integrate the REST API V2, whether it is a new application or an existing one that migrates from REST API V1 or SDK.

For more information about migration details and steps, see the next sections too.

Registration Phase FAQs

1. What’s the purpose of the Registration Phase? registration-phase-faq1

The purpose of the Registration Phase is to register the client application against Adobe Pass Authentication through the Dynamic Client Registration (DCR) process.

The Dynamic Client Registration (DCR) process requires the client application to obtain a pair of client credentials and retrieve an access token as the end goal of the Registration Phase.

For more information, refer to the Dynamic Client Registration Overview documentation.

2. Is the Registration Phase mandatory? registration-phase-faq2

The Registration Phase is mandatory, but the client application can skip this phase if it has a cached pair of client credentials and an access token that are still valid.

3. What’s a software statement and how long is it valid? registration-phase-faq3

The software statement is a term defined in the Glossary documentation.

The software statement consists of a JSON Web Token (JWT) that can be generated and downloaded from the Adobe Pass TVE Dashboard by one of your organization administrators or by an Adobe Pass Authentication representative acting on your behalf.

The software statement is valid for an unlimited timeframe, but you may choose to ask an Adobe Pass Authentication representative to revoke it at any time.

The client application must store the software statement and use it when needing to retrieve client credentials.

For more details, refer to the Dynamic Client Registration Overview documentation.

4. How to generate and download a software statement? registration-phase-faq4

This operation can be completed through the Adobe Pass TVE Dashboard by one of your organization administrators or by an Adobe 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.

5. What happens if a software statement is revoked? registration-phase-faq5

When the software statement is revoked, there is one important consequence to consider:

  • The client applications using the revoked software statement will no longer be able to go through the entitlement flows, meaning that users will get blocked from playing content.

6. What are client credentials and how long are they valid? registration-phase-faq6

The client credentials are a term defined in the Glossary documentation.

The client credentials consists of a client identifier and client secret pair that can be retrieved from the Client Register endpoint.

The client credentials are valid for an unlimited timeframe.

The client application must store indefinitely the client credentials and use them when needing to retrieve an access token.

For more information, refer to the Retrieve client credentials documentation.

7. How to manage client credentials? registration-phase-faq7

We recommend the client application to manage a unique pair of client credentials for each user application instance in case of both client-to-server and server-to-server integrations with Adobe Pass Authentication.

The client application must store indefinitely the client credentials and use them when needing to retrieve an access token.

8. What happens if cached client credentials are lost? registration-phase-faq8

When cached client credentials are lost, there are three important consequences to consider:

  • The client application must obtain a new pair of client credentials.
  • The client application must obtain a new access token using the new pair of client credentials.
  • The client application will need to ask the user to re-authenticate, as the client application will lose access to the authenticated profiles obtained before.

9. What’s an access token and how long is it valid? registration-phase-faq9

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

The access token consists of a bearer token that can be retrieved from the Client Token endpoint.

The access token is valid for a limited and short timeframe specified at the moment of issue.

The client application must store the access token and use it until it expires when targeting REST API V2.

The client application must obtain a new access token before the current one expires to prevent unauthorized requests.

For more information, refer to the Retrieve access token documentation.

10. How can the client application refresh an access token? registration-phase-faq10

The client application must refresh an access token the same way as retrieving a new access token, but using cached client credentials.

The client application must not re-register to refresh an access token, instead it must use the stored client credentials, otherwise users would be required to re-authenticate.

For more information, refer to the Retrieve access token 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 saved by Adobe 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’s 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 “Picker” 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 Adobe Pass Authentication to ensure the list is up-to-date and accurate.

The client application would receive an error from Adobe 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 Adobe 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 Adobe Pass TVE Dashboard by one of your organization administrators or by an Adobe 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. 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:

For more details, refer to the following documents:

3. How can the client application get the user’s 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:

For more details, refer to the following documents:

4. What’s 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:

5. What’s 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’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, 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:

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’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 or find the method used to authenticate.

For more details, refer to the following documents:

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 Adobe Pass TVE Dashboard by one of your organization administrators or by an Adobe Pass Authentication representative acting on your behalf.

For more details, refer to the TVE Dashboard Integrations User Guide 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:

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 Adobe Pass TVE Dashboard by one of your organization administrators or by an Adobe 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 to verify 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:

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 Adobe Pass Authentication before requiring to query the MVPD again.

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

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

4. What’s 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:

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’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 Adobe 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 Adobe Pass protected APIs.

The Authorization header value must be obtained from Adobe Pass Authentication during the Registration Phase.

For more details, refer to the following documents:

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.

Migration FAQs migration-faqs

Continue with this section if you are working on an application that needs to migrate an existing application to REST API V2.

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.

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

Adobe 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. 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 Adobe Pass TVE Dashboard by one of your organization administrators or by an Adobe 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 Adobe Pass Authentication representative to enable the usage of REST API V2 for your new registered applications (software statements), until the Adobe 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 “RESTV2”.

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

Migration from REST API V1 to REST API V2 migration-rest-api-v1-to-rest-api-v2-faqs

Continue with this subsection if you are working on an application that needs to migrate from REST API V1 to REST API V2.

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 Adobe Pass Authentication through the Dynamic Client Registration (DCR) process and obtain an access token.

For more information, refer to the following documents:

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:
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:
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:
Initiate (MVPD) authentication GET
/api/v1/authenticate		 GET
/api/v2/authenticate/{serviceProvider}/{code}

For more details, refer to the following documents:
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:
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:
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:
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:
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:
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:
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:
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:

Migration from SDK to REST API V2 migration-sdk-to-rest-api-v2

Continue with this subsection if you are working on an application that needs to migrate from SDK to REST API V2.

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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
recommendation-more-help
3f5e655c-af63-48cc-9769-2b6803cc5f4b