---
title: "Attach the transaction hash of your USDT send"
method: PATCH
path: "/v1/orders/{id}"
tags: ["Partner API"]
---

# Attach the transaction hash of your USDT send

`PATCH /v1/orders/{id}`

## Request

- Base URL: `https://sandbox.onlink.africa`
- URL: `https://sandbox.onlink.africa/v1/orders/{id}`
- Auth: API key in header `X-OnLink-Key`

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.

## Path parameters

- `id` string, required

## Request body

- AttachTxHashDto
  - `txHash` string, 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.

## Response `200`

Hash attached

- AttachTxHashResponseDto
  - `orderId` string, 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.
  - `txHash` string, 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.

## Other responses

- `400`: txHash is not a Tron transaction hash
- `404`: Order not found
- `409`: A different hash is already attached (`TX_HASH_ALREADY_ATTACHED`), the hash is already on another of your orders (`TX_HASH_ALREADY_USED`), the order is not a sell order (`ORDER_NOT_SELL_SIDE`), or it has already left `awaiting_usdt` (`ORDER_NOT_AWAITING_USDT`)

---

[API](https://skmtc.dev/onlink/apis/onlink-partner-api.md) - [All operations](https://skmtc.dev/onlink/apis/onlink-partner-api/llms.txt) - [OpenAPI document](https://skmtc.dev/onlink/apis/onlink-partner-api/revisions/1d1c6a3671f2?raw)