Processed-Orders Channel
This article explains the subscription and server messages produced in the Processed-Orders channel.
Subscription Messages
Subscription messages have the following formats:
websocket.send (JSON.stringify(
{ action: 'subscribe',
book: 'btc_mxn',
type: 'processed-orders' })){
"action": "subscribe",
"response": "ok",
"time": 1455831538047,
"type": "processed-orders"
}Server JSON Messages
The server's returned payload contains an array with one order in the following form:
| Field Name | Description | Type | Units |
|---|---|---|---|
a | The amount | String | Major |
d | Unix timestamp | Number | Milliseconds |
o | Order ID | String | |
r | The rate | String | Minor |
s | Order status Valid values: open, cancelled, and completed. The definitions of each state are below the table. | String | |
t | Possible values:
| Number | |
v | The value | String | Minor |
z | Timestamp of the last update (excluding Open orders) | Number | Milliseconds |
The order can be in one of three possible states:
- COMPLETED: An order appears as completed when the service has matched the order for its whole amount or value, meaning it was never added to the book.
- CANCELLED: The order was cancelled during processing and thus never added to the book.
Orders in OPEN state are not posted on this channel, only in the diff-orders channel. Notice that the payload format is the same for both channels; this is to simplify client-side implementation.
Example of Server Messages
Messages on the Processed-Orders channel for completed and cancelled orders look like this:
{
"type": "processed-orders",
"book": "btc_mxn",
"sequence": 2734,
"payload": [
{
"o": "laasdqw1ywYgfYI2",
"d": 1790971347838,
"r": "22222",
"t": 0,
"a": "0.25",
"v": "5312.25",
"s": "completed"
}
],
"sent": 1790971382117
}{
"type": "processed-orders",
"book": "btc_mxn",
"sequence": 2222,
"payload": [
{
"o": "laasdqw1ywYgfYI2",
"d": 1790971347838,
"r": "22222",
"t": 1,
"a": "0.25",
"v": "5312.25",
"s": "cancelled"
}
],
"sent": 1790971526216
}When placing an order, it's possible that it gets processed and the notification about it posted on this channel before the API call returns. This means that by the time the order's OID is received via API, the notification has already been sent. For this reason, we strongly recommend temporarily this flow to properly monitor an order via this channel:
- Subscribe to the channel if you haven't already
- Start listening to the incoming messages and store every order received
- Place your order
- Receive OID in the API response
- Search for the OID in the messages already received, as well an in any incoming messages
- Once you have the message, you can discard all the other ones.
Updated about 6 hours ago
