Do I need to be aware of request execution status when using the API?¶

Repro’s APIs have a rate limit on the number of requests per unit of time. If the limit is exceeded, a 429 Too Many Requests error is returned. Therefore, it is important to design your requests with rate limits in mind.

Rate Limit Specifications¶

The rate limit per unit of time varies by feature. They are as follows.

Feature	Rate Limit
Audience API	15 requests per 10 minutes per API token
Push API	1000 requests per minute per API token
User Profile API	1000 requests per minute per API token
User Profile Bulk Import API v3	10 requests per 10 minutes per API token
User Deletion API	1000 requests per minute per API token
News Feed API	3000 requests per minute per Client token

Note

Rate limits are set per API token for each feature. For example, the Push API and User Profile API share the same API token, but since they are different features, requests made simultaneously are counted separately for each.

When the number of requests exceeds the rate limit, HTTP Status 429 (Too Many Requests) is returned.

Current Usage Status¶

You can monitor the current usage status using the following HTTP headers included in API responses.

Header Name	Description
`X-RateLimit-Limit`	Rate limit per unit of time
`X-RateLimit-Remaining`	Number of remaining requests
`X-RateLimit-Reset`	Time when the rate limit resets (unixtime)
`Retry-After`	Number of seconds until retry is possible

How to Handle Rate Limits¶

We recommend implementing both measures: preemptively controlling the system based on the HTTP headers included in the API response and appropriately handling rate-limit errors.

Before Reaching the Limit¶

Use X-RateLimit-Remaining and X-RateLimit-Reset to control the number of requests so that they do not exceed the limit.

When Remaining is getting low, increase the interval between requests.
Wait until the Reset time to prevent exceeding the limit.
Avoid concentrating requests in a short period of time.
Batch requests together when possible.

When the Limit is Reached¶

When the rate limit is exceeded and 429 Too Many Requests is returned, use Retry-After to implement retry logic.

Wait for the duration indicated by the Retry-After value.
If 429 Too Many Requests occurs again, wait longer and retry.
Avoid consecutive retries in a short period of time.

Warning

When 429 Too Many Requests is returned, extend the wait time by at least 1 second beyond the Retry-After value. Even after waiting for the Retry-After duration, 429 Too Many Requests may be returned again due to sub-second timing differences.