Migration guidelines and known limitations

Cache your tokens.
They stay valid for 24 hours. Reuse 1 token until shortly before it expires, instead of requesting a new token on every API call.
Rate limit.
Stay under 40 token requests per hour, per client. Caching should cover normal usage. Build retry and backoff handling for the rare case you reach the limit.
Refresh proactively.
Renew your token a few minutes before the 24-hour expiry. This avoids a failed call from an expired token.
Rotate secrets on a schedule.
Rotate your Client Secret at least annually, and immediately if you suspect exposure. Don't wait for an incident.
Store credentials securely.
Treat your Client ID and Secret like any other production credential. Use a secrets manager. Avoid embedding them in the source code or client-side applications.
Use 1 token per product.
If you call more than 1 API product, cache a separate token for each product.
Select Client Assertion if your organization can manage a key pair.
This removes the risk of someone intercepting or leaking a shared secret in transit.

User applications (authorization code)

PKCE is mandatory.
Thomson Reuters Account requires PKCE for every User Application, including both public and confidential clients.
For single-page apps, understand the XSS risk before you store tokens in localStorage.
Follow current OWASP guidance for your client type, or use a backend-for-frontend pattern where possible.
Request only the scopes you need.
Minimize what you ask the user to authorize.
Use refresh tokens to avoid repeated logins.
Rotate or revoke them if you detect suspicious activity on an account.
Register redirect URIs precisely.
Avoid wildcard or overly broad redirect URI patterns.

Keep endpoints straight.
Use 2 different URLs. Use the Thomson Reuters Account token URL to authenticate. Use the existing product API URL to call the API.

Known limitations

1 audience per token.
A token can't span multiple API products. Multi-product integrations need a separate cached token per product.
Scope terminology changed.
Thomson Reuters Account now expresses scopes relative to an audience, not by name directly. If you reference scopes explicitly, review the updated audience-to-scope mapping in your onboarding materials.
Transfer exclusivity.
A Machine Application uses either Client Credentials or Client Assertion, never both. A user applicaton uses an Authorization Code instead, and it can't share an identity with a Machine Application.