Rate Limiting

To keep the platform fast and reliable for everyone, the Pronto API rate limits requests per organization. Every access token issued for your organization draws from the same shared budgets, so multiple integrations running under one organization share their limits.

Request cost tiers

Every endpoint is assigned a cost tier based on the work it causes on our side. Each tier has its own budget: your organization's combined traffic on all endpoints of a tier draws from one shared pool.

Endpoints currently classified as Tier 3:

• POST /chats/{chat_id}/messages — send a message
• PUT /chats/{chat_id}/memberships/{user_id} — update a membership
• DELETE /users/{user_id} — delete a user
• POST /users/{user_id}/send-welcome-message — send a welcome message
• POST /users/me/webhooks — create a webhook
• POST /files/{file_key}/normalized — normalize an uploaded file

Endpoints currently classified as Tier 1:

• GET /organization/users — list organization users

All other endpoints are Tier 2.

The classification of an endpoint can change over time. The rate limit headers returned on every response (see below) are the authoritative source for the limit that applies to a request.

Separate pool for import batches

The import batch endpoints have their own dedicated pool at Tier 2 (60 requests / 10 seconds), so running a large user import does not eat into the budget of your other API traffic — and vice versa:

• POST /organization/import_batches
• GET /organization/import_batches
• GET /organization/import_batches/{import_batch_id}
• PUT /organization/import_batches/{import_batch_id}/cancel

Rate limit headers

Every API response includes headers describing the budget your request was counted against:

When you exceed a limit, the response additionally includes:

429 - Too Many Requests

Requests over the limit are rejected with HTTP status 429. No work is performed for a rejected request, and it does not need to be deduplicated on your side — simply retry it after the window resets.

{
  "message": "Too Many Attempts."
}

Handling rate limits

• Respect Retry-After. When you receive a 429, wait at least the indicated number of seconds before retrying. Retrying earlier only returns another 429.
• Back off exponentially. If you retry programmatically, add a growing delay (with jitter) between attempts rather than retrying in a tight loop.
• Watch X-RateLimit-Remaining. For batch-style work, throttle your own request rate when the remaining budget runs low instead of running into the limit.
• Spread bulk operations. Limits are measured in 10-second windows, so a burst of requests hits the limit much sooner than the same requests spread evenly over a minute.
• Remember limits are shared per organization. If several integrations run under the same organization, they compete for the same budget — coordinate heavy jobs so they don't run at the same time.

If your integration has a legitimate need for higher limits, contact Pronto support to discuss the options for your organization.