Submits a token operation (a mint, burn, transfer, lock, release or cancel) and returns it. The operation then settles asynchronously; nothing further is required of the caller.
Acceptance and settlement
A 202 is acceptance, not completion. It means the request was well-formed and the accounts it names are usable. Every operation is then subject to the organisation's transaction policy, which may refuse it or hold it for an approver.
That outcome is not reported on this endpoint; read the operation back with GET /api/transactions/{transactionId} to see where it got to.
Supported token operations
txType decides the operation. MINT issues tokens to accountRef; BURN redeems tokens from it; TRANSFER moves tokens from accountRef to counterpartyRef, and is the one type that requires a counterparty; LOCK commits part of the account's balance; RELEASE and CANCEL complete a lock.
A release pays the lock's destination, or returns the funds if none was named, while a cancellation always returns them to the source and, unlike a release, still works once the lock has expired.
Related endpoints
FREEZE and UNFREEZE are not accepted here. They are account-control operations, raised through POST /api/accounts/{accountRef}/controls; sending either as a txType on this endpoint is a 400. DEPLOY is not accepted here either: a contract deployment is raised through POST /api/contracts, which shapes the factory call's arguments itself.
Account and contract requirements
Both accountRef and counterpartyRef name accounts, never customers. Each named account must exist, hold the operation's assetId, and be ACTIVE. The asset must have an ACTIVE contract; a missing one is a 400 on this endpoint, though the same condition is a 404 when registering an account.
Lock destinations
A lock is one-party or two-party, decided by counterpartyRef alone: named, and releasing the lock pays that account; absent, and the funds can only return to accountRef. This is fixed when the lock is created.
Completing a lock
A RELEASE or CANCEL carries txType and params.lockId, and nothing else. The asset, account and amount are read from the lock. Supplying assetId, accountRef or amount is a 400 for each. The lock must exist and currently be ACTIVE; a second completion while one is already in flight is a 400.
A lock that does not exist is a 404, and that one is worth retrying; see the 404 response below.
Returned call arguments
The response echoes the operation's call arguments in params, including those the service supplies itself. A LOCK is assigned its lockId here, and this response is where a caller obtains it: it is the identifier a release or cancel must name. A caller cannot choose it: a lockId supplied on a LOCK is a 400.
Balance checks
Balances are not checked at submission. An operation for more than the account holds is accepted here and fails during settlement.

