Rate limits

The authenticated API permits 60 requests per minute per authenticated user. Requests that cannot be associated with a user are limited by client IP address.

Response headers tell you how much of that allowance remains:

• X-RateLimit-Limit: maximum requests in the minute.
• X-RateLimit-Remaining: requests left in the current minute.
• Retry-After: seconds to wait; present on a 429 Too Many Requests response.
• X-Request-ID: identifier for this individual attempt.

Rate limits protect the service and can change as capacity and abuse controls evolve. Treat the response headers, rather than a hard-coded timer, as the source to follow.

Operation-specific limits

Creating a new store is limited to one per user every 60 seconds across all credentials. Replaying a successful store-creation request with its original Idempotency-Key returns that store without consuming another creation.

Exports allow one queued or running job per store and two per requesting account across stores and credentials. Capacity failures return 429 with Retry-After: 60. Poll the existing export instead of creating repeated jobs. These limits apply in addition to the general request limit.

Handle 429

Pause requests until Retry-After has elapsed. If further retries are needed, wait longer between attempts and add a random delay; this is exponential backoff with jitter. Set a maximum number of attempts or a time limit. A 429 does not mean the write ran successfully, but retry writes only when the operation is inherently idempotent or uses a documented key.

To make fewer requests, cache data that rarely changes, avoid fetching the same page repeatedly, and combine duplicate requests from your own workers. Use webhooks for supported events instead of repeatedly asking whether something changed.