Search Orders API (querying closed_at time) is rather inacurrate

Questions
1

I am trying to get all of the newest orders for a user that I don’t already have. For example: when a user logs in to my website, the website automatically fetches all of the newest orders, that are not already stored in the website database. I do this by time. I take the most recent transactions in the database, increment the time a little bit, then use that for start_at.

The problem with this, is that I keep getting returned that exact order that I check the time of. I have to add an entire second before I stop getting that order. This seems impracticle if the user potentially has different devices and you could have two orders that go through in the same second.

Am I missing something here, or is the API just that inaccurate?

2

If the orders are all being created by the API, then you could subscribe to order webhooks, which would let you know when one has been created or updated.

Otherwise, could you explain your use case a bit more? I’m not sure what you mean by the API being inaccurate. If you are trying to retrieve all orders from a given second onward, and two orders were generated on that second, then it makes sense that both orders would be returned in the query. With that said, you can get down to a fraction of a second as well. For instance, one of my orders has this:

"created_at": "2021-03-01T22:00:57.458Z",

Meaning I can query on it like so:

      "query": {
          "filter": {
              "date_time_filter": {
                  "created_at": {
                      "start_at": "2021-03-01T22:00:57.458Z",
                      "end_at": "2021-03-01T22:00:57.459Z"
                  }
              }
          }
      }
3

For example, I download the order that you show above. A little later, I want to download any order created after that one, not including it. So I use your query but with this change:

"created_at": {
    "start_at": "2021-03-01T22:00:57.459Z",
    "end_at": variable_representing_now
}

When I do this, I still recieve the order that you show. In fact, I still get that order even if I change it to this:

"created_at": {
    "start_at": "2021-03-01T22:00:57.558Z",
    "end_at": variable_representing_now
}

I have to increase it by an entire second. So, let’s imagine this order:

"created_at": "2021-03-01T22:00:57.499Z",

I will not receive this order if I increase the time by one second. On the other hand, if I don’t increase it by one second, then I end up with a duplicate of the order that you show. I hope I was able to make myself clear there.

I checked out the webhooks and it seems that it is beta and doesn’t work with any POS at the moment, this makes it not someting that I can use.

4

I’m not able to replicate this behavior. Do you have some example order ids? For example, I have an order that has "created_at": "2021-03-01T22:00:57.458Z". If I do:

                  "created_at": {
                      "start_at": "2021-03-01T22:00:57.458Z",
                      "end_at": "2021-03-01T22:00:57.499Z"
                  }

I get the order as expected. If I do:

                  "created_at": {
                      "start_at": "2021-03-01T22:00:57.459Z",
                      "end_at": "2021-03-01T22:00:57.499Z"
                  }

(1 microsecond later), then I no longer receive the order.

5

I’ll double check this to make sure that I didn’t make a mistake and send you the order ID’s. I’ll get back to you on this in a day or two when I have a bit of time.

6

I discovered the problem and it is my fault. I was storing the date-time from “created_at” and then comparing that to “closed_at”. I checked it using “closed_at” and it worked perfectly. I only need to add a single millisecond and it gave me what I expected. Thanks.

1 Like