When querying the get orders endpoint without a since_id value set, the orders are returned in a descending order, but when I query with the since_id they are ascending. This creates an issue when you make a first query without the since_id, but attempt to set it for the remaining orders. You end up using the last order from the first query which is in descending order. Then you ask for orders since that id, and the result will be the orders you received in your first query excluding the order used in the since_id but in ascending order.
First query limit of 5 returns
Using 1205384413228 as the since_id, which is the recommended method of pagination results in the next result.
These are the orders from the first query ordered in reverse and excluding the since_id value.
I think that returning resources in ascending order with since_id makes sense as a concept, since you want everything after a specific ID, counting forward. Without since_id, the REST APIs had always been in descending order as a default state. That said, I can see where you're coming from, and I have a solution that might work for you.
You don't have to give an existing ID to since_id. If you want a starting point, since_id=0 will always start at the absolute first ID. You can then paginate off the last ID in these returned resources.
I hope that helps, and thanks for the feedback.
Thanks for the response. We were able to move forward. I just wanted to note the experience in case anyone else runs into the same issue.
In our case we ended up setting the since_id to null, which works the same as setting the value to 0. What we found, which led to this entire investigation, was that when we set the since_id to 0 we were receiving internal server errors for some of the brands we work with. This led to experimenting with how we make the request. Unfortunately, I can't publicly share information about the partners we work with but I'm happy to share in a private thread.
|3 hours ago|