Migrate API applications to Thomson Reuters Account
Prepare to migrate API applications from Apigee to Thomson Reuters Account (Auth0).
Thomson Reuters Account is our standards-based identity platform. Apigee remains in place and continues to handle API governance, including quotas, analytics, and product access. Downstream API calls work the same way they do today.
Learn how Thomson Reuters Account manages your application, generates a token, and uses the token to call our APIs. This applies whether you migrate from an existing application or onboard a new one. It covers 3 application and transfer types.
Application type | Transfer | Typical use case |
|---|---|---|
Machine Application (M2M) | Client Credentials | Server-to-server integration; authenticate with a Client ID and Secret |
Machine Application (M2M) | Client Assertion (JWTCA) | Server-to-server integration; authenticate with a signed JWT instead of a shared secret |
User Application | Authorization Code | A web or mobile application acting on behalf of a signed-in end user |
note
This change affects only authentication. It doesn't affect authorization.
- Your product entitlements, scopes, and quotas stay the same. Apigee continues to manage this layer.
- The request/response pattern for calling our product APIs stays the same. Only how you obtain and present your token changes.
- Existing application configuration transfers over when you migrate, including your products, scopes, and settings.
What's changing
Area | Today (Apigee) | After migration (Thomson Reuters Account) |
|---|---|---|
Identity provider | Apigee generates and validates client credentials | Thomson Reuters Account (Auth0) issues identity; Apigee validates the token. |
Token type | Apigee-generated token | Thomson Reuters Account (Auth0)-issued JSON Web Token (JWT); no opaque token. |
Token endpoint | Apigee token URL | Thomson Reuters Account token URL: auth.thomsonreuters.com/oauth/token. |
Client credentials | Apigee generates the Client ID and Secret | Thomson Reuters Account generates the Client ID and Secret. |
Client assertion (JWTCA) | You authenticate with a signed JWT instead of a shared Client Secret, using the private_key_jwt method | Authenticate with a signed JWT instead of a shared Client Secret, using the private_key_jwt method. The signed JWT construction parameters change. |
API call headers | Authorization: Bearer <opaque token> | Authorization: Bearer <token>. Send the same header; the token is now a Thomson Reuters Account (Auth0) JWT instead of an opaque token. |
Token validation | Apigee performs a lookup | Apigee validates the token locally and instantly, using Thomson Reuters Account's public signing keys. This adds no latency. |
End-user sign-in (User Applications) | Apigee handles sign-in with ONESOURCE Universal Login | Thomson Reuters Account handles sign-in through the standards-based Authorization Code transfer. |
Benefits of Thomson Reuters Account for API applications
- Modern, standards-based tokens:Thomson Reuters Account (Auth0) replaces Apigee's opaque token with a signed JSON Web Token (JWT). This is an industry-standard, verifiable format.
- No added latency:Apigee validates your token locally against Auth0's published signing keys. This adds no round trip.
- 1 identity platform:you already use a Thomson Reuters Account for sign-in. It now also handles machine and user-delegated authentication.
- Optional key-based authentication:Client Assertion (JWTCA) uses a signed JWT instead of a shared secret. This lowers the risk of interception in transit.
- Governance stays put:Apigee continues to enforce your product entitlements, quotas, and analytics. This migration changes only the identity and token layer.
Upgrading and managing your applications
Thomson Reuters Account registers each application as an identity, whether it's a machine or user application. Apigee no longer registers applications on its own.
Apigee continues to associate your application with the API products and scopes you're entitled to. This governance layer doesn't move.
Changes for all application types
- Thomson Reuters Account generates and manages your application's Client ID. Depending on the transfer, it also manages your Client Secret, signing key, or redirect URI.noteApigee continues to enforce product entitlements and quotas. This doesn't change.
- Each application across multiple products gets its own Thomson Reuters Account Client ID and credential material.
Rollout phases
Phase | Provider selection |
|---|---|
Initial rollout | Customers have the option to select an application provider when they onboard a new application. Select Apigee or Thomson Reuters Application. |
Mandated for new applications | Thomson Reuters application becomes the default provider for new applications, with no option to select otherwise. Thomson Reuters Account onboards all new applications as Thomson Reuters applications. |
Final stage — full mandate (target: March 31, 2027) | Fully migrate all applications, including existing Apigee applications, to the Thomson Reuters application. Thomson Reuters Account no longer supports Apigee as an application/provider option from this point onward. |