Working on an Order API integration for a community module. Wanted to avoid rewriting the Mage_Sales_Model_Order_Api model, so instead I implemented an observer of the sales_order_collection_load_before event that limits the result set to a hard limit. Went with 250, that's the limit Shopify uses, seems like a sane number if you're going to hard code something.

If there are API integrations that depend upon the order API not having any limit, then they could run into issues. For example, if someone has an Order API integration that pulls in the full number of orders on a monthly basis (or even a daily basis, the time range is somewhat arbitrary), then it would now only pull in 250 orders.

While it's possible to filter the result set on a date range, any date range that you pick would be essentially arbitrary. A day's worth of orders might be way too small and result in an unnecessarily high number of API hits for smaller stores, and for larger stores, it might be way too large of a range. It really is necessary to be able to limit an API response on an absolute number of results, and that's what most modern API's do.

Has anyone found any good solution to this?

  • Why not implementing a check in the observer and set the limit dynamically? Commented Feb 13, 2013 at 9:58
  • An efficient way to do this: have a script locally that generates a json files with the orders I need and store it in a protected folder. The "client" has access to the protected folders and gets these json files, parses them instead of using the API requests. Much more faster. Commented Feb 13, 2013 at 11:24
  • @FabianBlechschmidt, I implemented a check in the observer and set a hard limit dynamically. That's exactly the issue though is that there's a hard limit. Commented Feb 13, 2013 at 16:40
  • 1
    Looks like Ashley Schroeder answered me: twitter.com/aschroder/status/301556872530505728 :) I think that's a good solution. Commented Feb 13, 2013 at 16:41
  • 1
    Ashley's solution is elegant, nice. Commented Feb 13, 2013 at 17:04

1 Answer 1


A fix was found in the comments but I'm adding a formal answer so it can be marked as solved and people searching in the future can see easily.

Solution provided by Ashley Schroeder on twitter

Summarised answer:

We back off progressively if we detect big responses. i.e try for 24hours, then back off to 6*4hours. ...
If the connection drops or gets too big we bail out and fall back, it's recursive so if 4hour is too big we split again.

Also thats for fetching historical data, for frequent real time window is typically 10-20minutes, same splitting applies though

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.