Agreement Manager API rules and resource limits

This page lists the rate limits, and other restrictions on using the Agreement Manager API.

API rate limits

The Docusign Agreement Manager API enforces rate limits to ensure service reliability and fair access across all integrations. Requests that exceed these limits receive an HTTP 429 Too Many Requests response.

Rate limits are enforced per account for most requests. When a request does not carry an account identifier in the URL path, the limit is applied per OAuth client (the sub or userId claim in the access token) instead.

The Agreement Manager API enforces the following API call rate limits:

No burst allowance is available beyond this limit.. The dimension applied to a given request depends on whether the request URL contains an accountId path parameter:

• Account-scoped requests (such as GET /accounts/{accountId}/agreements) are counted against the per-account limit.
• Non-account-scoped requests are counted against the per-OAuth-client limit (identified by the userId/sub value of your JSON Web Token).

Note: These rate limits are not shared across environments. A separate limit is applied for the developer and the production environments.

Rate limit error response

When a request is rejected after hitting the rate limit, the API returns:

Example response header

HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: text/plain
Rate limit exceeded. Please try again later.

The Retry-After value is always a whole number of seconds (ceiling-rounded) and is safe to use directly as a sleep duration before retrying.

Best practices

Use the Retry-After header to create a cool-down period. Read the Retry-After value from the 429 response and wait at least that many seconds before retrying the request. Retrying immediately will result in additional 429 responses without making progress.

Use exponential backoff. If you receive repeated 429 responses after waiting for Retry-After, apply exponential backoff between retries. Start with the Retry-After value and double the wait on each subsequent failure.

Distribute requests evenly. Avoid issuing requests in bursts. Spreading 600 requests uniformly across a minute (one every 100 ms) is more reliable than sending all 600 in rapid succession at the start of the minute.

Cache responses where appropriate. For read-heavy workflows, such as listing agreement types or retrieving account settings that change infrequently, caching API responses client-side reduces the number of requests counted against your limit.

Use bulk endpoints. Where the API offers batch or list endpoints, prefer them over making individual requests in a loop. A single GET /accounts/{accountId}/agreements call with pagination consumes one request against your limit regardless of the number of items returned.