In 14 years of WordPress work I have seen a lot of quick and dirty code, and one of the most common shortcuts is hitting a REST endpoint with per_page=0 to get everything at once. It saves you from writing pagination logic. WooCommerce 10.6, slated for March 2026, ends that shortcut by enforcing a minimum limit: the WooCommerce Store API per_page parameter for products and reviews now requires a value of at least 1.
Any external integration or custom front-end block still passing per_page=0 is about to start collecting 400 Bad Request errors. The change is a performance safeguard. I have watched stores with 5,000+ products fall over because someone asked the API for the whole catalog in one call. Pagination is there for memory management.
Why WooCommerce is restricting the per_page argument
It comes down to stability. Ask for a WooCommerce Store API per_page value of 0 and the server tries to fetch every matching record. On a small dev site that works fine. On a production site with thousands of products or reviews you hit a race condition or run out of memory before the response even starts, and the payload that does come back is slow enough for users to notice.
The change landed in Pull Request #61755. The API now requires a value between 1 and 100. If you are already tuning your site, this pairs with my earlier notes on WooCommerce REST API caching.
The fix: batch your requests
Refactor the call into batches. Ask for 100 items a page and iterate until you run out of pages. Memory stays flat and responses come back quickly.
So instead of the old request, use /wc/store/products?per_page=100&page=1, then read the X-WP-TotalPages header to see whether there is a page 2 to fetch. This is where the earlier piece on optimizing performance with lazy loading applies.
The quick workaround (use with caution)
Reality is messy, and sometimes a legacy system cannot be refactored overnight. The rest_endpoints filter lets you put the minimum back to 0. Know what you are doing there: it is a safety net you are switching off. The official documentation covers the Store API architecture if you want the background.
<?php
/**
* Restore support for per_page=0 in WooCommerce 10.6 Store API.
* Prefixing with bbioon_ to avoid collisions.
*/
add_filter( 'rest_endpoints', 'bbioon_restore_store_api_all_results' );
function bbioon_restore_store_api_all_results( $endpoints ) {
$routes = [ '/wc/store/products', '/wc/store/products/reviews' ];
foreach ( $routes as $route ) {
if ( ! isset( $endpoints[ $route ] ) ) {
continue;
}
foreach ( $endpoints[ $route ] as &$handler ) {
if ( isset( $handler['args']['per_page'] ) && is_array( $handler['args']['per_page'] ) ) {
// Set the minimum back to 0 to allow fetching all records
$handler['args']['per_page']['minimum'] = 0;
}
}
}
return $endpoints;
}If this WooCommerce Store API per_page change is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
Audit your API calls before March
Don’t wait until March 2026 to find out the site is broken. Search your Store API calls for per_page=0 now and turn each one into a paginated loop. Your server holds up better under load, and you avoid the frantic “the site is down” call on release day. The WooCommerce developer blog has more on the rest of the 10.6 changes.
