I’ve seen a lot of “quick and dirty” code in my 14 years of WordPress development, and one of the most common shortcuts is hitting a REST endpoint with per_page=0 to just “get everything.” It’s a classic move when you don’t want to deal with pagination logic. However, the upcoming WooCommerce 10.6 release (slated for March 2026) is putting an end to this by enforcing a minimum limit. Specifically, the WooCommerce Store API per_page parameter for products and reviews will now require a minimum value of 1.
If you have external integrations or custom frontend blocks relying on the per_page=0 argument, your site is about to start throwing 400 Bad Request errors. This isn’t just a random change; it’s a performance safeguard. I’ve personally seen stores with 5,000+ products crash because a developer tried to load the entire catalog in a single API call. Pagination exists for a reason: memory management.
Why WooCommerce Is Restricting the per_page Argument
The logic behind this update is simple: stability. When you request a WooCommerce Store API per_page value of 0, the server tries to fetch every matching record. On a small dev site, it works fine. On a production site with thousands of reviews or products, you hit a race condition or an out-of-memory error before the response even starts. Furthermore, large payloads degrade the user experience via high latency.
This change was detailed in Pull Request #61755. The API will now strictly require a value between 1 and 100. If you are already optimizing your site, you might recall my previous advice on WooCommerce REST API caching to keep these requests fast.
The Correct Fix: Implementing Batched Requests
The professional way to handle this is to refactor your code to use batches. Instead of asking for everything at once, request 100 items per page and iterate until you reach the end. This keeps the memory footprint low and the response times snappy.
For example, instead of your old request, use: /wc/store/products?per_page=100&page=1. Then, check the X-WP-TotalPages header in the response to know if you need to fetch page 2, 3, and so on. We’ve talked about optimizing performance with lazy loading before, and this is exactly where that logic applies.
The Quick Workaround (Use with Caution)
I know reality is messy. Sometimes you have a legacy system that you can’t refactor overnight. In that case, you can use the rest_endpoints filter to revert the minimum requirement back to 0. Just be aware that you are essentially disabling a safety net. For more details on the Store API architecture, check the official documentation.
<?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;
}Look, if this WooCommerce Store API per_page stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway: Ship More Scalable Code
Don’t wait for March 2026 to find out your site is broken. Audit your API calls now. If you’re using the Store API, search for any instance of per_page=0 and refactor it into a paginated loop. It’s better for your server, better for your users, and it stops you from getting that frantic “the site is down” call on release day. For more on the upcoming 10.6 changes, refer to the WooCommerce Developer Blog.
