REST API V2 FAQs rest-api-v2-faqs
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.
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.
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.
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:
- Profiles endpoint API
- Profiles endpoint for specific MVPD API
- Profiles endpoint for specific (authentication) code API
For more details, refer to the following documents:
- Basic profiles flow performed within primary application
- Basic profiles flow performed within secondary application
3. How can the client application get the user’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:
- Profiles endpoint API
- Profiles endpoint for specific MVPD API
- Profiles endpoint for specific (authentication) code API
For more details, refer to the following documents:
- Basic profiles flow performed within primary application
- Basic profiles flow performed within secondary application
4. What’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:
- Create authentication session API
- Resume authentication session API
- Basic authentication flow performed within primary application
- Basic authentication flow performed within secondary application
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:
- Create authentication session API
- Resume authentication session API
- Basic authentication flow performed within primary application
- Basic authentication flow performed within secondary application
6. How can the client application know if the user typed a valid authentication code and that the authentication session did not expire yet? authentication-phase-faq6
The client application can validate the authentication code that is typed by the user in a secondary (screen) application by sending a request to the Sessions endpoint responsible to retrieve authentication session information associated with the authentication code.
The client application would receive an error if the provided authentication code would be typed wrong or in case the authentication session would be expired.
For more information, refer to the Retrieve authentication session documentation.
7. What’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:
- Profiles endpoint API
- Profiles endpoint for specific MVPD API
- Profiles endpoint for specific (authentication) code API
- Basic profiles flow performed within primary application
- Basic profiles flow performed within secondary application
The profile is valid for a limited timeframe specified when queried, indicating the amount of time the user has a valid authentication before requiring to go through the Authentication Phase again.
This limited timeframe known as authentication (authN) TTL can be viewed and changed through the 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.
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. 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.
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.
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.
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:
- Dynamic Client Registration Overview
- Retrieve client credentials API
- Retrieve access token API
- Dynamic Client Registration Flow
In case the client application is migrating from REST API V1 to REST API V2, the client application can continue to use the same method to obtain the Bearer access token as before.
2. How to compute the value for the AP-Device-Identifier header? headers-faq2
The AP-Device-Identifier request header contains the streaming device identifier as it was created by the client application.
The AP-Device-Identifier header documentation provides some examples of how to compute the value for different platforms, but the client application can choose to use a different method based on its own business logic and requirements.
In case the client application is migrating from REST API V1 to REST API V2, the client application can continue to use the same method to compute the device identifier as before.
3. How to compute the value for the X-Device-Info header? headers-faq3
The X-Device-Info request header contains the client information (device, connection and application) related to the actual streaming device.
The X-Device-Info header documentation provides some examples of how to compute the value for different platforms, but the client application can choose to use a different method based on its own business logic and requirements.
In case the client application is migrating from REST API V1 to REST API V2, the client application can continue to use the same method to compute the device information as before.
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.
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.
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:
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 |
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:
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:
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:
For more details, refer to the following documents: |
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: |
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:
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:
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:
For more details, refer to the following documents: |
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: |
Migrate from SDK to REST API V2 migrate-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.
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: |
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 |
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
For more details, refer to the following documents: |
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: |
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} |
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} |
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} |
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} |
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 |
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 |
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 |
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 |