Rate Limits
Two separate limits apply, one to authentication and one to everything else.
| Requests | Limit | Scope |
|---|---|---|
Authentication (/login) |
10 per hour | Per user |
Performance (e.g. /ad_units) |
10 per minute | Per account |
In any case of rate limit violation the response status will be 429 (Maximum request limit reached).
Managing tokens#
Given the limitation on login token requests, the recommended way to manage tokens is to store an active token to be used in all requests, and periodically update it. Since each token is valid for 30 days, the update period should be 30 days or less.
Don’t log in per request
Calling /login before each performance request will exhaust the authentication limit after ten requests in an hour, even though the performance limit is far higher. Generate a token once, cache it, and refresh it on a schedule or when you get a 401.
Backing off#
A client that hits 429 should wait rather than retry immediately. If you are pulling a wide date range broken down several ways, request it once and cache the result — the unconfirmed_revenue_dates field in every response tells you which dates in your range are still subject to change.