Rate limiting

Breet enforces rate limits to ensure platform stability and fair usage across all integrations.

Limits

Endpoint	Limit
`POST /payments/withdraw/address`	200 requests per minute
`POST /payments/wallet-addresses`	5 requests per minute
All other endpoints	500 requests per minute

Rate limits are applied per integration and per route. This means hitting the withdrawal endpoint does not affect your rate limit on the withdrawal-addresses endpoint, and vice versa. Limits are tracked using the authentication credentials (x-app-id) in your request headers. Route-specific limits replace the default 500 for that route only.

Response headers

Rate-limited endpoints include the following headers in every response:

Header	Description
`X-RateLimit-Limit`	Maximum number of requests allowed per window (e.g., `200`).
`X-RateLimit-Remaining`	Number of requests remaining in the current window.
`X-RateLimit-Reset`	Unix timestamp (in seconds) when the rate limit window resets. Included on every response.
`Retry-After`	Number of seconds to wait before retrying. Only included on `429` responses.

Example response headers

X-RateLimit-Limit: 200
X-RateLimit-Remaining: 199
X-RateLimit-Reset: 1769099817

Handling rate limits

When you exceed the rate limit, the API returns a 429 Too Many Requests status code. See error handling for the full 429 response format. To handle this gracefully:

Check the X-RateLimit-Remaining header before making requests. If it is approaching 0, slow down.
If you receive a 429 response, use the Retry-After header (value in seconds) to determine how long to wait before retrying.
Add a retry loop so transient rate limit hits don’t break your integration.

Example retry logic

async function withdrawWithRetry(payload, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch("https://api.breet.io/v1/payments/withdraw/address", {
      method: "POST",
      headers: {
        "x-app-id": APP_ID,
        "x-app-secret": APP_SECRET,
        "X-Breet-Env": "production",
        "Content-Type": "application/json",
      },
      body: JSON.stringify(payload),
    });

    if (response.status !== 429) return response.json();

    const retryAfter = response.headers.get("Retry-After");
    const waitMs = Number(retryAfter) * 1000;
    await new Promise((resolve) => setTimeout(resolve, Math.max(waitMs, 1000)));
  }

  throw new Error("Rate limit exceeded after retries");
}

Best practices

Batch operations where possible to reduce the total number of API calls.
Monitor headers proactively. Don’t wait for a 429 to start throttling.
Queue withdrawals on your end and process them at a steady rate below the limit.

Getting started

Core concepts

Use cases

Limits

Response headers

Example response headers

Handling rate limits

Example retry logic

Best practices

​Limits

​Response headers

​Example response headers

​Handling rate limits

​Example retry logic

​Best practices

Limits

Response headers

Example response headers

Handling rate limits

Example retry logic

Best practices