Understanding Data Sources on SPOT API

Since the API in Binance is asynchronous, some endpoints may be slower in the response time than others.

So situations like this can happen:

Hey I sent an order to the Engine but when I queried my order via GET /api/v3/order, it’s says my order doesn’t exist! HELP!


I deleted my order but when I ran GET api/v3/order it says it’s still there, so I tried to delete it again but DELETE /api/v3/order says “Unknown order”! What happened?!

So this post will hopefully explain what’s going on, and for cases like the above which endpoint to refer to when there’s a discrepancy of information.

In the API Documentation, there are 3 Data Sources, ordered by the most up-to-date response

  • Matching Engine
  • Memory
  • Database

How can I distinguish between the three?
Endpoints usually sourcing from the Matching Engine are usually POST endpoints, such as POST api/v3/order,
Endpoints sourcing from Memory are usually Market Data Information, such as GET api/v3/exchangeInfo, or GET api/v3/depth
Endpoints sourcing from a Database are usually order or account information, such as GET api/v3/order or GET api/v3/allOrderList

The API Documentation should show all SPOT endpoints with their corresponding Data Source for reference.

Example #1:

Let’s say a User is sending an order to the Engine via POST api/v3/order. The engine will respond that the order was sent successfully and give the orderId 345

Then upon running GET api/v3/order using orderId 345, it throws an error saying “Order does not exist”.

Since the response from POST api/v3/order is coming from the Matching Engine, this confirms that the order has been created. So for this scenario the user should refer to this result as what actually happened.

Example #2

A user queries their order using GET api/v3/order with orderId 489 and confirmed the order is still open.
When they send a cancel request via DELETE api/v3/order, they receive a response that the cancel is completed.
The user, wanting to be 100% sure, runs GET api/v3/order again but gets a response that the order is still open.

Similar to example 1, DELETE api/v3/order data is from the Matching Engine, so the user should refer to that instead of GET api/v3/order.

Hope that helps!