Authentication Token API rate limiting
Learn more about rate limiting for the Authentication Token API, how the service responds when the limit is exceeded, and practices for managing access tokens.
The Reltio authentication service applies a rate limit to requests to POST /oauth/token on auth.reltio.com. The rate limit is evaluated per source IP address over a rolling time window, so requests from systems that share the same public IP address are counted together.
The limit is intended to protect the availability of the authentication service when an unusually high volume of token requests is sent from the same source IP address. In normal integration patterns, , store it securely, and reuse it until it expires. Integrations that follow this pattern are not expected to be affected by the rate limit.
The following table describes where the rate limit is applied and how it is evaluated.
| Item | Value |
|---|---|
| Regions | EU, US, and AP |
| Endpoint | POST /oauth/token on auth.reltio.com |
| Limit scope | Per source IP address, per rolling time window. The rate limit is evaluated per source IP address, not per tenant, user, or OAuth client. |
| Limit window | Rolling time window |
Response when the limit is exceeded
When a source IP address exceeds the permitted request rate, the authentication service returns HTTP 429 Too Many Requests for requests from that source IP address. The condition is temporary, and access recovers automatically after the request rate decreases.
This response doesn't result in a lasting account or IP address lockout. If your source IP address exceeds the rate limit, take the following actions:
- Reduce the rate of token requests from the affected source IP address.
- Allow time for the request rate to return to an acceptable level. Access generally recovers within a minute.
- Retry the request using exponential backoff, with a longer wait between each attempt.
You don't need to contact Reltio Support for standard rate-limit recovery.
Recommended practices
Use the following practices to reduce unnecessary requests to the Authentication Token API.
| Practice | Recommendation |
|---|---|
| Cache and reuse access tokens | Store access tokens securely and reuse them until they expire. Access tokens are valid for 60 minutes by default unless the client is configured with a different validity period. Request a new token near expiry or after a 401 response indicates the existing token is no longer valid. |
| Use exponential backoff after HTTP 429 | Retry requests with increasing delays after an HTTP 429 Too Many Requests response. Don't retry immediately in a tight loop. |
| Contact Support for exceptional high-volume needs | If your integration generates a high volume of authentication requests and may be affected by rate limiting, submit a support request for proactive review. You can request a review before receiving HTTP 429 Too Many Requests responses. |
| Account for shared egress IP addresses | Some deployment environments route traffic from multiple applications or workloads through the same public IP address by using NAT, VPN, proxy, or cloud egress. Requests that use the same public egress IP address are evaluated together for rate limiting. Use a shared token cache or token service so that individual processes do not independently generate unnecessary token requests through the same source IP address. |
Practices to avoid
Use the following practices to avoid request patterns that can increase the likelihood of rate limiting.
| Practice | Reason |
|---|---|
| Requesting a new token for every API call | Repeated token requests create unnecessary load on /oauth/token and increase the likelihood that requests from the source IP address will be rate limited. |
| Retrying immediately after HTTP 429 | Tight retry loops can keep the source IP address above the permitted request rate and delay recovery. |
Frequently asked questions
- Will my integration be affected?
- Only integrations that request access tokens at an unusually high rate from a single source IP address are expected to be affected. Integrations that cache and reuse access tokens until expiry aren't expected to be affected.
- What is the exact rate limit?
- The specific rate-limit threshold isn't disclosed and may change over time based on platform usage. If your integration sends a high volume of authentication requests, contact reltio support for review.
- Does rate limiting change authentication or token contents?
- No. Successful authentication, the token endpoint, and token contents are unchanged. Requests that exceed the permitted rate from a source IP address receive
HTTP 429 Too Many Requests. - Which regions does rate limiting apply to?
- Authentication Token API rate limiting applies in the EU, US, and AP regions.
- How do I recover from HTTP 429?
- Reduce the token-request rate from the source IP address. Access recovers automatically, typically within about a minute. Use exponential backoff for retry attempts, then return to caching and reusing access tokens.