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 carries the payment instructions, our paymentReference, and — once your payment has been matched — the provider’s own references for it: the M-PESA/PesaLink code your customer recognises, plus the bank’s transaction id. A SELL order carries the deposit address and the transaction hash you attached.
Authorization
partner-key In: header
Path Parameters
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", "expiresAt": "2026-09-01T09:30:00.000Z", "depositAddress": "TQiBwkXtUUNygiLdSwdeaZCKagwPsD1a7C", "chain": "tron", "sendBefore": "2026-09-01T09:30:00.000Z", "txHash": "5d6a3c7b1e4f2a908c6d5b4a3928170f6e5d4c3b2a1908f7e6d5c4b3a2918070"}Attach the transaction hash of your USDT send PATCH
This is what attributes your deposit to this order. Attaching a different hash to an order that already has one is refused (409), never an overwrite — the first hash may already have been matched, and re-pointing the order would orphan a real deposit. 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 you send us on (buy leg) and your USDT deposit address (sell leg). Every reference is an explicit field — the KES accountReference is the exact value to put in the M-PESA account-number field or the bank narration. Your USDT deposit address is permanent and shared across all your sell orders, so it cannot identify which order a deposit is for; attach the transaction hash with PATCH /v1/orders/{id}.