Performance Guidelines: Rate and Burst Limit Considerations

Rate Limit

Cobre's public API supports 30 transactions per second (TPS) under steady-state operation. To ensure consistent performance and avoid HTTP 429 (Too Many Requests) errors, we strongly recommend following these API best practices:

Implement exponential backoff with retry logic.

Use idempotency keys on all sensitive operations.

Avoid aggressive polling patterns.

Optimize request frequency and batching where applicable.

Rely on Webhooks for asynchronous updates whenever possible.

Efficient API usage helps maintain low latency, high reliability, and predictable behavior — even under peak traffic conditions.

Burst Limit

In addition to the sustained rate limit, each client's API key has a burst limit of 200 requests, implemented using a token bucket algorithm. This bucket holds up to 200 tokens (one per request) and refills at a rate of 30 tokens per second — matching the steady-state rate limit.

This means:

That 200-request allowance is a one-time buffer, not a repeatable per-second cap. Once consumed, it only refills at 30 tokens/second, so sustained traffic above 30 TPS will deplete the bucket and eventually trigger HTTP 429 responses.

For example: if you fire 100 requests in the first second while the bucket is full, all 100 succeed and the bucket refills by 30 (now at 130/200). But if you sustain 50 requests/second continuously, the 200-token buffer depletes within roughly a few seconds, after which excess requests are throttled to the 30 TPS refill rate until your request volume normalizes.

Important: Because all credentials under a single client share one underlying API key, creating multiple credentials (e.g., for different services or use cases) does not increase available throughput.

To avoid burst-related throttling, we recommend:

Smoothing request distribution — spread requests evenly over time rather than sending them in large batches.

Implementing a token bucket or leaky bucket algorithm on your side — these patterns naturally absorb bursts while respecting rate boundaries.

Monitoring 429 responses proactively — treat them as a signal to back off immediately and retry with exponential delay.

Avoiding synchronized retries — if multiple processes retry simultaneously after a failure, it can amplify the burst. Add jitter to retry intervals.

Performance Guidelines: Rate and Burst Limit Considerations

Rate Limit#

Burst Limit#

Rate Limit

Burst Limit