Rate Limits

Extend enforces rate limits at the organization level to ensure system stability and fair resource allocation.

How rate limits are structured

Rate limits are applied per category. Each category has its own rate limit, and hitting the limit for one category does not affect the others.

Endpoint request limits are grouped by operation type:

• GET — read endpoints (retrieving runs, listing resources, fetching results)
• WRITE — mutating endpoints that don’t trigger processing (creating processors, updating configuration)
• RUN — endpoints that submit files for processing (running processors, running workflows, batch endpoints)

Processor throughput is a separate limit on the number of files processed per minute across your organization. One unit of throughput equals processing one file through any of the following operations:

• Classification
• Extraction
• Splitting
• Parsing
• Editing

Limits by plan

Workspace-level rate limits

Organization admins can set per-workspace rate limits that apply on top of the organization’s limits. This is useful for protecting workspaces from potential overuse by a single team or environment, and for ensuring more equitable distribution of resources across your organization.

• Workspace limits can only be set below the organization’s limit for each category.
• If a workspace limit is not set, the workspace inherits the organization’s limit.
• Organization-wide limits always apply, even if the sum of workspace limits exceeds them.

Handling rate limits

When you exceed a rate limit, the API responds with HTTP 429 Too Many Requests and the error code RATE_LIMIT_EXCEEDED. This error is retryable — see Error Handling for the full error shape.

1
HTTP/1.1 429 Too Many Requests
2
Content-Type: application/json
3
4
{
5
  "code": "RATE_LIMIT_EXCEEDED",
6
  "message": "Too many requests. Back off and retry.",
7
  "retryable": true
8
}

To handle this gracefully:

• Back off and retry. Retry the request with exponential backoff and jitter. If a Retry-After header is present on the response, wait at least that many seconds before retrying.
• Prefer async for volume. For high-throughput workloads, use the asynchronous run endpoints and batch processing rather than driving many synchronous calls.

The official SDKs retry retryable responses (including 429) automatically with backoff.

Need higher limits?

The + on the Scale and Enterprise tiers indicates the limits are negotiated and tied to committed volume — they start at the listed value and increase from there. If you’d like to get higher rate limits, please reach out to the Extend team.