Rate Limits

The Poptin API applies rate limits to keep the platform stable and fair for every account calling it. This page explains the model at a conceptual level and tells you where to find the current numbers. Design your client to expect limits, not to avoid them.

How limits work

• Limits apply per API token. When you authenticate with a pk_live_ key, usage is counted against that specific token - not the account as a whole. Separate keys for separate integrations give each workload its own budget.
• A general limit covers most Public API routes. Read-heavy operations such as listing poptins, retrieving contacts, or reading conversions fall under this shared limit.
• Some operations use stricter limits. Sensitive or expensive actions - for example template email sends and bulk import / delete jobs - enforce tighter caps than the general limit.
• Other caps may apply per operation. Individual endpoints may also constrain payload size, row counts, concurrency, or impose cooldowns between calls. These are documented alongside the operation itself.

Where to find current limits

Concrete numbers - requests per minute, per-endpoint caps, payload ceilings - live with each operation in the API Reference. Treat the Reference as the source of truth. Do not hardcode limits from third-party sources, past support threads, or older versions of this page; they change.

If a limit isn't shown for a specific operation, the general Public API limit applies.

Rate limit headers

Use these response headers to understand the active limit and decide when to retry:

Header availability can vary for endpoint-specific cooldowns, so clients should always handle 429 responses even when a particular header is absent.

Handling 429 responses

When you exceed a limit, the API returns HTTP 429 Too Many Requests. Treat this as a temporary, recoverable condition:

1. Honor Retry-After when present. If the response includes a Retry-After header, wait at least that long before retrying.
2. Back off exponentially. For repeated 429s (or when no Retry-After is provided), retry with exponential delay - for example 1s, 2s, 4s, 8s - with jitter to avoid thundering herds.
3. Cap your retries. After a bounded number of attempts, surface the failure to your caller or queue instead of hammering the API.
4. Avoid tight polling. Long-running work runs as async jobs - poll job status on an interval, not in a hot loop. See Async jobs for the recommended pattern.

Well-behaved clients rarely see 429s. When they do, they retry cleanly and keep going.

Related