Getting 404 for cancelled as well as filled orders (at some instance)

Exchange/Pro API
1

Hi ,
Iam using the coinbase pro trading apis in my application . I use the get single order api (https://api.exchange.coinbase.com/orders/{order_id}/) to fetch the status of the order and update it in my application . I found that while querying the cancelled orders , it gives me 404 .
But at some instance even the filled order is giving 404 . We are not using sockets for the updates of orders as there is a chance of missing the updates during system maintainence or downtime. Please help me out of this issue

2

Hello @Bejo! Thank you for posting your concern here at the Coinbase Developer forum.

It is called out in this documentation that "If the order is canceled, and if the order had no matches, the response might return the status code 404 ". So querying a canceled order is expected to return a 404 error response.

With regards to the filled order, can you share the steps you took to arrive at the 404 error response? Also, is the order_id that you are using listed when calling the Get all orders endpoint?

We hope we clarified your concern regarding cancelled orders getting 404 error response. Looking forward to your answers to the questions mentioned above. Have a great day! :sunny:

3

hi @ereeca15 ,
Order id - ad04bc3e-b838-4d62-9769-a703245d37f5
created time -06-02-23 9:36:23 pm IST
filled in exchange - 06-02-23 9:36:26 pm IST
get single order query - 06-02-23 9:36:31 pm IST . I got 404 in this specific time frame

4

Hello @Bejo! We appreciate your prompt response as well as the details you have provided. With this, can you confirm if you are still able to receive the same 404 error message when trying to call for the Get Single Order endpoint now? If yes, can you provide us with the screenshot of the error you are receiving? Please ensure to remove any sensitive information that may compromise your account. Otherwise, please also let us know so we could determine how we could best assist you.

Nonetheless, we wish to inform you that we are already looking into this with our internal teams and we’ll get back to you once we have more information. We will also be looking forward to your response. Thank you!

5

Hi @ereeca15 , Now im getting it with done status . But when my system queried the order at that specific time frame , I got 404 and my system saved it as cancelled order in the data base . So iam trying to get more clarity about it .

6

Hi @ereeca15 , do we have any information regarding this issue?

7

Hi @Bejo! We sincerely apologize if our response is taking longer than usual. Our team is still looking into this and will get back to you once we have any updates.

We appreciate your patience and understanding.

8

Hi @Bejo ! Thank you for your patience as we look into this.

Based on the information we gathered from the relevant teams, a 404 error message is expected to be returned when a user makes a request via our REST endpoint to cancel an outstanding order that was already filled. While on the other hand,
when an order is filled, there are several steps that occur all before the data is made available for customers to query.

Our clearing process needs to settle the trade post match on our trade engine, which at times can take seconds or longer if there is high system load. Once the trade is settled in our database, there is additional lag replicating that data into the replica databases we use to serve clients with the Get Single Order REST requests. That too can experience several seconds of delays or more during high system stress.

When things are running smoothly, these delays should be very short, but we have seen them take minutes at times. Hence, we suggest that clients make use of our real-time web-socket feed to subscribe to the “user” channel which should deliver this information faster than polling our REST given the above caveats. You may pass the query string ?product_id=[PAIR] as outlined in this documentation.

Additionally, please note that when cancelling orders via REST, several checks are necessary when the user cancels an order without specifying the product_id, these extra checks might lead to possible race conditions due to the database replication.

  • Good:
    DELETE /orders/784461ee-7833-4f68-8ca0-b9179ce84818?product_id=BTC-USD

  • Bad:
    DELETE /orders/784461ee-7833-4f68-8ca0-b9179ce84818p

We hope we have provided clarity with your concerns. Have a great day! :sunny: