WordPress core ships its REST API open by default with no built-in request cap. Any throttling developers hit comes from added layers, not from core itself. The WordPress REST API is the HTTP interface apps use to read and write posts, pages, media, and store data. Developers should therefore look to plugins, hosts, and their own client behavior when requests get blocked.
Table of Contents
- Where do WordPress limits actually come from?
- How does WooCommerce limit its Store API?
- What about the 100-item page limit?
- How should you build to avoid 429s?
Where do WordPress limits actually come from?
In production, caps usually come from security plugins, host firewalls and WAFs, and server rules. According to One Two Three Send, those layers commonly impose per-IP or per-endpoint caps and return HTTP 429 when exceeded in how plugins enforce caps.
That matters because the same sync can pass on one host and fail on another. A migration script, mobile app, or headless front end may be fine until a firewall rule counts rapid calls from one IP as abuse. Check the active security plugin, host dashboard, and server logs first when 429s appear.
How does WooCommerce limit its Store API?
WooCommerce offers separate, opt-in protection for its Store API. It is disabled by default and configured only through the `woocommerce_store_api_rate_limit_options` filter, with a default of 25 requests per 10 seconds, as described by WooCommerce Developer Docs in the Store API rate-limiting reference. The limiter tracks logged-in callers by user ID and guests by IP address.
It applies only to POST requests and exposes `RateLimit-Limit`, `Remaining`, `Reset`, and `Retry-After` headers, with support for custom fingerprinting and proxy header handling. The protection began with Blocks 8.9.0 and WooCommerce 7.2 in late 2022 to defend checkout, cart, and product endpoints. According to the WooCommerce Developer Blog, it also included an interface option limiting checkout place-order calls to 3 requests per 60 seconds in the rate-limiting announcement.
What about the 100-item page limit?
Separately from throttling, collection responses cap pagination at `per_page=100`. WordPress Developer Resources explains that responses return `X-WP-Total` and `X-WP-TotalPages` headers in its pagination guide.
That cap is normal behavior, not punishment for making too many calls. A bulk post sync, media export, or search index build must request page one, read the total-pages header, then loop through the remaining pages and combine results. Asking for 500 items at once will not bypass the ceiling.
How should you build to avoid 429s?
Authenticate server-to-server calls, cache repeat reads, and paginate large pulls. Read limit and reset headers on every response, honor 429 and `Retry-After` with backoff, and slow down checkout and cart writes especially. Test rapid checkout, add-to-cart, and sync flows against staging with the same firewall and WooCommerce settings as production.
- Cache product, post, and settings reads instead of polling them
- Queue imports and updates in small batches with pauses between pages
- Retry 429s after the supplied delay, with longer waits after repeat blocks
- Enable proxy-support options behind a CDN or load balancer so all visitors do not appear as one IP, a practice recommended by TopSyde in its hosting and security guide
