Rate Limits & Retries
Design integrations that handle temporary failures without creating unnecessary load or duplicate operations.
Reliable API integrations should account for request throttling, transient network errors, and temporary service interruptions.
Retry behavior must be appropriate for the operation being performed.
Rate limits
APIs may enforce limits on the number of requests accepted within a defined period.
Limits may vary by product, environment, endpoint, or integration.
Consult the relevant API reference for documented rate limits.
HTTP 429
An HTTP 429 Too Many Requests response generally indicates that a request has exceeded an applicable rate limit.
Where a Retry-After header is provided, applications should interpret it according to HTTP specifications and the API's documented behavior.
Do not assume that every rate-limited response includes this header.
Retry strategies
For operations that are safe to retry, exponential backoff can help reduce repeated requests during temporary failures.
An illustrative delay sequence is:
| Attempt | Example delay |
|---|---|
| First retry | 1 second |
| Second retry | 2 seconds |
| Third retry | 4 seconds |
| Fourth retry | 8 seconds |
These values are examples, not prescribed Senmo retry intervals.
Adding random jitter can reduce simultaneous retry attempts from multiple clients.
Operations requiring special care
Some operations change persistent business state.
Examples include:
- Creating financial transactions.
- Posting ledger entries.
- Initiating payments.
- Transferring digital assets.
- Issuing or redeeming vouchers.
For these operations, an unsuccessful HTTP response or network timeout does not always establish that the operation was not performed.
Before retrying, use the documented idempotency or reconciliation mechanism where available.
Avoid unlimited retries
Applications should define reasonable retry limits and failure-handling procedures.
Repeated failures may indicate an invalid request, unavailable dependency, configuration issue, or permanent business-rule rejection.
Recommended practices
- Use request timeouts appropriate to the operation.
- Retry only when the operation is safe to repeat.
- Respect documented rate limits and retry headers.
- Use exponential backoff with jitter where appropriate.
- Avoid retrying validation and authorization failures without correcting the underlying issue.
- Record failed attempts without exposing credentials.
- Investigate uncertain outcomes before repeating state-changing operations.
Next steps
Continue with Idempotency to understand how applications can reduce the risk of duplicate operations.
Updated about 4 hours ago