Rate limiting
Rate limiting is a cap on how many requests a client may send to a server within a set period; once a caller reaches that cap, the server rejects or delays its next requests until the period resets, so no single caller can exhaust the capacity other callers depend on.
Submit a project See the Laravel mobile app backend guideReviewed by Huy Nguyen (David), CEO · Updated 30 Oct 2026 · 5 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while planning an API a mobile app, a storefront or another system will call.
Why does rate limiting matter?
The IETF standard for this behaviour, RFC 6585, defines the response a server sends once a caller goes over its cap: "The 429 status code indicates that the user has sent too many requests in a given amount of time." RFC 9110, the IETF's HTTP semantics standard, adds the header a server can use to say when it is safe to try again: servers send the "Retry-After" header field "to indicate how long the user agent ought to wait before making a follow-up request." OutsourcingVN is operated by Netbase JSC, and the reason a buyer should ask about this before a build starts is that an integration with no plan for a 429 response either fails outright at the first busy moment or retries blindly and makes the same server busier.
What is an example of rate limiting in practice?
An integration resyncs stock levels to a storefront every few minutes and, during a sale, starts sending calls faster than the storefront's own API allows. The storefront's server returns a 429 response with a Retry-After value, and a well-built client waits that long before trying again rather than retrying immediately and being rejected a second time. Because the resync call can run more than once without changing the final result, waiting and retrying is safe; the idempotency entry covers what has to be true about a call for that to hold.
What are the common misreadings of rate limiting?
A limit a provider sets on calls you make to its API is not the same as a limit you set on calls other clients make to your own API; the first is a constraint your integration has to live with, the second is a design decision you make yourself, and a project can face both at once. Rate limiting is also not a separate idea from Laravel's "throttling": Laravel's own routing documentation names the feature "Rate Limiting" and implements it through what it calls the "throttle" middleware, treating the two words as the same mechanism rather than two different ones. And a rate limit is not the same as a usage quota for a billing period: a rate limit caps how fast calls may arrive within a short window to protect real-time capacity, while a quota caps a total amount of use over a longer period.
Plan the next step for your project
Common questions
Wait before retrying: RFC 9110 defines the Retry-After header precisely so a client knows "how long" to wait "before making a follow-up request," rather than guessing or retrying immediately.
Through the throttle middleware: Laravel's routing documentation states that "rate limiters may be attached to routes or route groups using the throttle middleware," and that Laravel automatically returns a 429 response once a request exceeds the configured limit.
Shopify's own API documentation states the general reason plainly: "Rate limits keep the platform stable and fair for everyone," so no single caller can degrade the service other callers depend on.
No. Both RFCs describe only the signal that a client has gone over a cap and a hint at how long to wait; whether a retried request is safe to repeat depends on the call itself, which is what idempotency covers separately.
Which decisions does rate limiting affect?
Deciding where a rate limiter sits and what it protects is one of the parts the Laravel mobile app backend guide plans for an API a mobile app calls, and the production AI inference assessment checks rate limiting from a hosted model API as one of the conditions a fallback path has to handle. A webhook delivery arriving faster than a receiver can process is the same capacity problem from the other direction, inbound rather than outbound. When you know which of your own calls or endpoints need a limit, describe them and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.