Deactivate an orchestration address
Soft-delete the address: sets status=DEACTIVATED and deactivatedAt=now().
Requires a walletAddress in the body — any deposits still PENDING (not yet
rolled into a batch) are refunded in-kind to it. The claim and refund run
atomically under the address row lock, so a deposit can never be both
offramped and refunded. Idempotent — calling on an already-deactivated address
returns 200 with the current record and issues no second refund.
After deactivation:
- The on-chain wallet still exists and can receive funds (we can’t take it offline).
- Incoming deposits are recorded with
status=IGNOREDandignoredReason=ADDRESS_DEACTIVATED. A Slack alert fires for manual ops follow-up. These are NOT auto-refunded — only the deposits that werePENDINGat deactivation are. - The escrow wallet stays locked to this address (it’s never returned to the general allocation pool).
- Batches already in
PROCESSINGcontinue to completion; batches stillPENDINGwill be markedFAILEDwithfailureReason=ADDRESS_NOT_ACTIVEon the next worker tick.
Authorizations
Path Parameters
Body
Body for deactivating an orchestration address. Any deposits still PENDING
(not yet rolled into a batch) are refunded in-kind to walletAddress.
Response
A single orchestration address record.
An orchestration address record.
Optional payment message, preserved exactly. Wire allows at most four lines of 35 characters; ACH allows 10 characters; SWIFT allows 12. Only printable ASCII and newlines are accepted; backslashes and other control characters are rejected. Nonempty messages are unsupported for RTP and other rails. Missing, null, or empty means no message on create; on update omission preserves the setting and null or empty clears it. A destination change revalidates the saved or supplied message. Returns null when unset. Queued batches read current settings when initializing an offramp; initialized offramps retain their saved message on retry.
"Invoice 42"
Determines when deposits are converted into an offramp.
PER_DEPOSIT— each deposit is batched into its own offramp immediately, UNLESS the cumulativePENDINGamount is below the destination rail's offramp minimum, in which case the deposit is heldPENDINGand all pending deposits are batched together once their cumulative amount reaches the minimum.SCHEDULED— deposits accumulate until the next schedule boundary (HOURLY/DAILY/WEEKLY), then the entire pending pool is batched together (only if it meets the offramp minimum; otherwise it rolls into the next tick).THRESHOLD— deposits accumulate until their summed amount reachesthresholdAmount, then the entire pending pool is batched.
PER_DEPOSIT, SCHEDULED, THRESHOLD Lifecycle status of the orchestration address.
PENDING_WALLET— created but the escrow wallet is still being provisioned. The on-chainaddressis null. Typically transient (a few seconds).ACTIVE— wallet provisioned, ready to receive deposits.DEACTIVATED— soft-deleted. The on-chain wallet still exists and can receive funds, but incoming deposits are recorded withstatus=IGNOREDand never offramped.
PENDING_WALLET, ACTIVE, DEACTIVATED The escrow wallet's live on-chain balance of the source token. Present
ONLY on the single-address GET (GET /orchestration-addresses/{id}); the
list endpoint omits it to avoid a provider call per row. null if the
wallet isn't provisioned yet or the balance lookup failed — the GET still
returns 200.