OnLink
API reference

Read one of your orders

Scoped to your own orders: another partner’s order id returns 404, not 403. The shape follows the order’s side. A BUY order tells you where your KES debit stands. A SELL order carries the deposit address and the transaction hash you attached.

GET
/v1/orders/{id}

Authorization

partner-key
X-OnLink-Key<token>

In: header

Path Parameters

id*string

Your order id

Response Body

application/json

application/json

curl -X GET "https://example.com/v1/orders/string"
{  "orderId": "3a7c1f90-8b2d-4e56-9a01-cd23ef456789",  "status": "awaiting_usdt",  "kesAmount": "1281000.00",  "usdtAmount": "10000.000000",  "rate": "128.1000",  "kesTotalAmount": "1268180.00",  "fee": {    "kesAmount": "12820.00",    "currency": "KES",    "percentBps": 100,    "flatKesAmount": "10.00",    "capKesAmount": null  },  "expiresAt": "2026-09-01T09:30:00.000Z",  "depositAddress": "T9yD14Nj9j7xAB4dbGeiX9h8unkKHxuWwb",  "chain": "tron",  "sendBefore": "2026-09-01T09:30:00.000Z",  "txHash": "5d6a3c7b1e4f2a908c6d5b4a3928170f6e5d4c3b2a1908f7e6d5c4b3a2918070"}

Attach the transaction hash of your USDT send PATCH

Not part of the documented sell flow: we take your USDT at create, from your balance or from your own wallet, so there is normally no hash to attach. If you do hold a hash for a sell order that is still awaiting_usdt, this records it against that order. That is all it does: it does not move the order, release a payout, or confirm that the USDT arrived. Deposit matching later looks for a deposit carrying this hash and exactly the order’s USDT amount, and only a match moves the order on; a deposit with this hash but a different amount is held for review, not paid. Your deposit address is the same for every order, so the hash is the only link we use — we never infer the order from the amount. Sell orders only: a buy order is refused with 409 ORDER_NOT_SELL_SIDE, and so is any order that has already left awaiting_usdt — including a sell order paid from your USDT balance at create — with 409 ORDER_NOT_AWAITING_USDT. The hash is 64 hexadecimal characters, with or without a 0x prefix, and is returned lower-case without the prefix. An order takes one hash, and a hash can fund only one of your orders: a different hash on an order that already has one is refused (409 TX_HASH_ALREADY_ATTACHED), never an overwrite — the first hash may already have been matched — and a hash already attached to another of your orders is 409 TX_HASH_ALREADY_USED. Re-sending the SAME hash is safe and returns 200, so a retry after a lost response is fine.

Deposit instructions for both legs GET

The KES rails that top up your KES balance, and your USDT deposit address. A KES deposit is credited to your balance, not to any one order — a buy order debits that balance directly. Every reference is an explicit field — the KES accountReference is the exact value to put in the M-PESA account-number field, or the beneficiary account number on a bank transfer. Your USDT deposit address is permanent. What a deposit does depends on who holds your USDT: if OnLink holds it, USDT sent to the address tops up your USDT balance, which a sell order is paid from; if you hold it in your own wallet, the address is that wallet and the USDT stays there, where your sells and sends draw from it. GET /v1/usdt/holding-wallet says which applies to you.