Hi there,
(Note: I know the REST Admin APIs are marked legacy, but we’re still using the REST Order API which is still supported and we’ve been slowly migrating endpoints to GraphQL starting with the smaller ones.)
We have 1 Shopify Plus store customer that’s always getting a 500 Internal Server Error when requesting Orders with a created_at_min filter set to more than 7 days ago. We even tried requesting very minimal data (just the ID field) and just 1 record (limit=1) and it’s still always giving an Internal Server Error.
If we don’t include the created_at_min filter, the request goes through just fine.
One thing that stands out with this particular store is the store was created all the way back in 2014 and has a very large number of orders.
It seems the issue may be the API web server/proxy timing out, as it appears to return that error after about 17 seconds. So I think the query is simply taking longer to complete than the web server timeout.
It seems a bit of an edge case as we do see 500 errors occasionally for other stores as well, but they tend to resolve after 1 retry attempt. This store in particular just constantly gives the 500 error even after many retry attempts when including the created_at_min filter in the request.
Can someone from Shopify take a look? Maybe the index for this store is not optimized? Request ID below.
REST Admin Order API version: 2025-10
Sample Request: https://…/admin/api/2025-10/orders.json?limit=1&since_id=0&created_at_min=2026-01-01&fields=id&status=any
Request ID: cf02cbbb-c20c-4be0-ab33-e78bf24890a6-1768513559
Hey @Jonathan-HA - I pulled logs for your request ID and can confirm this is a database timeout. The query is timing out before it can return results, which explains the 500 after ~17 seconds.
This is a known issue affecting large/older stores when using created_at_min with the REST Orders API. When you filter by created_at_min on a store with a lot of historical orders, the query can end up doing a lot more work before timing out. The fact that it works without the date filter confirms this - without that filter, the query takes a different code path.
I see the Orders team have been doing some work on optimizing REST API queries lately, so I’ve raised your report with them internally to see what they think.
In the meantime, a few workarounds (which, to be fair, you’re already aware of!):
-
Use the GraphQL Admin API orders query with cursor-based pagination instead - it handles large datasets more gracefully
-
If you must use REST, consider removing created_at_min and filtering the results client-side after fetching
I’ll update this thread once I hear back from the team on whether additional optimization work is needed for this specific query pattern. Thanks for flagging this!
1 Like
@Donal-Shopify Thanks for looking into this Donal and looking forward to that update!
The workaround we’re doing for the time being is breaking up their reports by fulfillment_status. The query works fine with created_at_min and a specific fulfillment_status set, so it seems maybe that’s hitting a different index.
@Jonathan-HA Quick update - I checked with the Orders team and confirmed that the recent REST query optimizations don’t cover created_at_min-only queries.
The team has opened an internal ticket to look into optimizing this query pattern. I’ll update here once I hear back on progress.
In the meantime, your workaround of breaking up queries by fulfillment_status is a solid approach. If you need to stick with date filtering, adding updated_at_min alongside created_at_min should hit the optimized path - thanks for flagging this!
1 Like
Thanks for the update @Donal-Shopify !