Partner API

Attach the transaction hash of your USDT send

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.

patch/v1/orders/{id}

Request

  • Base URL
    https://sandbox.onlink.africa
  • Auth
    API key in header X-OnLink-Key

Path parameters

idstring required

Your order id

Request body

txHashstring required

The Tron transaction hash of your USDT send: 64 hex characters, with or without a 0x prefix. It is recorded on this order so a later deposit carrying the same hash can be matched to it — it does not move the order or release a payout. We never infer the order from the amount, because your deposit address is the same for every order.

Example request

{
  "txHash": "5d6a3c7b1e4f2a908c6d5b4a3928170f6e5d4c3b2a1908f7e6d5c4b3a2918070"
}

Response

Hash attached

orderIdstring uuid required

The order the hash is now attached to.

status'awaiting_payment' | 'awaiting_usdt' | 'payment_matched' | 'usdt_received' | 'funds_reserved' | 'awaiting_approval' | 'rejected' | 'sending' | 'paying_out' | 'settled' | 'expired' | 'review' required

The order’s status. Attaching a hash does not change it, so a first attach returns awaiting_usdt; it moves only when we match a deposit carrying this hash and exactly the order’s USDT amount. Attaching a hash is a claim, not a receipt. Re-sending the same hash later returns the order’s current status.

txHashstring required

The hash as stored: lower-cased, 0x stripped. Re-sending the same hash returns this unchanged (200); a DIFFERENT hash is refused (409), never an overwrite.

Example response

{
  "orderId": "3a7c1f90-8b2d-4e56-9a01-cd23ef456789",
  "status": "awaiting_usdt",
  "txHash": "5d6a3c7b1e4f2a908c6d5b4a3928170f6e5d4c3b2a1908f7e6d5c4b3a2918070"
}

Changes

No recorded changes to this operation across all 1 revision of this API.