Rate limiting
Rate limiting caps how frequently a client may make requests under a defined rule.
Rate limiting restricts the permitted frequency of requests. A rule may apply to an IP address, user or application, for example. The period, counting method and scope depend on the service.
A fictional API allows a client 100 requests per minute. Exceeding that limit may produce HTTP 429. An optional Retry-After header indicates a wait before another attempt; its interpretation depends on the actual service. The example is not an ASES or provider quota.
An integration should align its throughput and retries with the limit. A limit error does not mean the business data is invalid. A retry strategy handles later attempts; the limit defines permitted load.
Sources
Related terms
- Retry strategyA retry strategy defines which failures to retry, the waiting intervals and the limit on further attempts.
- Server-sent eventsServer-sent events carry text notifications from server to client over HTTP, for example about the progress of a background job.
- Entity tagAn ETag identifies a particular representation version of an HTTP resource and supports conditional reads or changes.
- Cross-Origin Resource SharingCORS controls browser access to responses across origin boundaries. It replaces neither API login nor permission checks.
- Electronic Data InterchangeEDI transfers structured business documents between systems. Format, partner profile, data mapping and responses need to agree.
- Real-time processingReal-time processing handles arriving events against a defined latency target. Event time, processing time and late data need explicit rules.
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.