Ecommerce API rate limiting: protect login and checkout without blocking customers

One limit for the whole store is the wrong limit

Rate limiting protects availability, cost and sensitive business flows, yet a uniform rule can become a self-inflicted outage. A failed login, a catalogue read, a cart update, payment initiation and a partner synchronisation consume different resources and create different customer consequences. Giving them the same window, counting key and action confuses abuse, promotional demand and legitimate behaviour.

OWASP treats unrestricted consumption of CPU, memory, bandwidth, storage and paid third-party services as an API risk. Its operational guidance is to tune limits to business needs and recognise that some endpoints require stricter policies. The goal is therefore not to choose a universal number. It is to design budgets, identities, priorities and degradation paths that protect login and checkout without making shopping brittle.

Prepare an inventory, identities and a baseline

Classify operations by real cost

Start with an inventory of routes, HTTP methods, authentication, dependencies and cost. Record whether each operation reads cache or database, changes state, calls a provider, starts asynchronous work or multiplies load through pagination, filters or batches. One request is not always equivalent to another. Shopify’s documentation, for example, describes GraphQL limits based on query cost and a bucket that restores capacity over time. It illustrates why raw request counts can be too coarse.

Choose keys that represent the subject

The initial matrix should attach four elements to every class: who is counted, what consumes the budget, which action occurs and how the client recovers. An IP address is a useful signal, not a dependable identity. Offices, mobile carriers and households may share one, while a bot can distribute traffic. Where available and appropriate, combine IP, session, account, client identifier, tenant and API credential. Pseudonymise sensitive identifiers and bound key cardinality.

• Login: budgets by IP and pseudonymised account identifier, with failed outcomes counted separately.
• Catalogue: an elastic budget for cacheable reads, separating expensive search, export and deep pagination.
• Cart: a session or user key, with different budgets for reads and mutations.
• Checkout: session, account and risk context, reserving capacity for journeys already in progress.
• Integrations: client, shop or tenant keys, combined with concurrency and cost limits.

Give every journey its own policy

Login and recovery: count the abuse signal

For login, observe total attempts and failed outcomes separately. Cloudflare documents separate counting and mitigation expressions, with backend response codes available to the counting logic. That supports a progression from observation to delay, additional verification and proportionate temporary blocking, instead of immediately banning all navigation. Preserve non-enumerating messages and an accessible path for legitimate users. Password recovery, OTP delivery and account creation need separate budgets because they have different abuse patterns and may incur external cost.

Catalogue: absorb demand and isolate expensive queries

Product and category pages must tolerate campaigns and flash sales. Use caching and edge delivery, allow bursts supported by the baseline, and constrain costly work more tightly: combinatorial search, unindexed sorts, exports, repeated scraping, deep pages and oversized batches. Also cap parameter size, collection length and execution time. OWASP makes clear that interaction frequency is only one part of resource control. Identified bots and authorised partners can have explicit policies, but never an unbounded bypass.

Cart: protect mutations without losing intent

A cart read differs from adding an item, removing one, recalculating a promotion or requesting delivery estimates. Limit mutations by session and make operations idempotent when they can be retried after a timeout. Under pressure, preserve saved state and postpone only a non-essential recalculation; do not empty the cart or turn a retry into a duplicate quantity. Investigate bursts caused by the frontend itself. Double clicks, retries without backoff and components calling the same API can resemble hostile traffic.

Checkout: reserve capacity and degrade precisely

Checkout deserves budgets and queues isolated from catalogue and back-office traffic. Separate session creation, address validation, shipping quotes, promotion application, payment-intent creation and status reads. Operations already in progress take priority over new work, while optional services can degrade without blocking essential steps. Idempotency, authentication and fraud checks remain separate controls; the limiter does not replace them.

Avoid a global rule based only on IP. A buyer on a shared network should not lose payment because other people are browsing. Combine signals, apply progressive verification where possible and keep a support route. Decide beforehand what clients may retry and when they must retrieve the existing transaction state instead.

Integrations: budget by client, cost and concurrency

ERP, PIM, marketplace and logistics APIs need quotas per credential and tenant, concurrency limits and queues for heavy work. Weight operations by cost rather than equating a point lookup with a broad synchronisation. When a provider exposes budget information, use it to pace work. Shopify, for example, returns GraphQL query-cost and throttle-status data. When an upstream limit is reached, apply bounded backoff with jitter, honour timing guidance and avoid amplifying pressure through parallel retries.

Coordinate edge, gateway and application controls

The edge absorbs obvious abuse and protects the origin. The gateway applies client and tenant quotas. The application knows the account, outcome and business cost. Workers and databases enforce concurrency, timeouts and capacity. Decisions should align without blindly duplicating counters. Document precedence, key, window, action, owner and emergency mode for every rule.

Return a 429 the client can handle

RFC 6585 defines 429 Too Many Requests for excessive requests in a period. The representation should explain the condition and may include Retry-After; the RFC does not prescribe how the server identifies a user or counts requests. For controlled APIs, return a stable body with a machine code, limit scope and correlation identifier without exposing fraud signals. Include Retry-After when the delay is reliable, and ensure the response is not cached.

In the storefront, disable only the affected action, preserve inputs and cart state, avoid automatic loops and show a useful message. Server-to-server clients should use bounded retries, backoff and jitter. During an extreme attack, a server might not answer every request with 429 because generating responses consumes resources; RFC 6585 explicitly allows other protective steps. Network and capacity controls therefore remain necessary.

Tune through progressive rollout and realistic tests

Begin in observation mode: record which rule would have acted without blocking. Build baselines by route, identity, country, channel, time, campaign and client version. Separate real buyers, known automation, unknown traffic and frontend errors. Derive thresholds from internal distributions and measured capacity, then test surges, shared NAT, retries, lost cookies, campaigns, slow queues and counter-store failure.

1. Deploy one policy to one endpoint class and a controlled share of traffic.
2. Correlate limiter decisions, origin responses and customer journeys with a common identifier.
3. Expand gradually while keeping expiring overrides and a tested kill switch.
4. Review rules after frontend, catalogue, campaign, provider or architecture changes.

Measure protection and protected customers

The dashboard should show allowed, delayed, challenged and rejected requests per policy; the share of 429 responses in apparently legitimate sessions; login success after verification; cart and checkout abandonment after a decision; latency, origin saturation and provider cost; compliance with Retry-After; and limiter availability and latency. Segment by route, key, action and version without uncontrolled high-cardinality labels.

The operational runbook before launch

Verify that each endpoint has an owner, cost class, identity, budget, action, response and dashboard. Test distributed invalid credentials, many accounts behind one IP, catalogue scraping, duplicate cart mutations, payment timeouts, partner batches, loss of the counter datastore and a sudden provider quota reduction. Confirm that the customer can continue or recover state in every scenario.

Good ecommerce rate limiting is a resilience policy, not one barrier. It differentiates journeys, preserves checkout capacity, makes clients cooperative and measures false positives beside blocked traffic. Explore our ecommerce and systems services for help designing gateways, observability and reliable flows. To review policies and rollout, contact AE Digital Agency.