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
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
ID of the user
ID of the orchestration address.
Body
Body for deactivating an orchestration address. Any deposits still PENDING
(not yet rolled into a batch) are refunded in-kind to walletAddress.
Destination address for the in-kind refund of the address's PENDING
deposits. Must be a valid address for the orchestration address's chain
(else 400 FIELD_VALIDATION_ERROR). Required even when there are no
pending deposits to refund.
Response
A single orchestration address record.
An orchestration address record.
Unique orchestration address ID.
ID of the user that owns this orchestration address.
The on-chain wallet address that accepts deposits. null while
status=PENDING_WALLET (provisioning in flight); populated once the
wallet exists.
"0xAbC0123456789AbCdEf0123456789AbCdEf01234"
Source token + chain the address accepts.
Destination payout configuration.
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 Populated only when mode=SCHEDULED; null otherwise.
Populated only when mode=THRESHOLD; null otherwise. Decimal amount
in the source currency.
"100.00"
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 ISO 8601 timestamp when the address was deactivated. null if still active.
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.
{
"currency": "usdc",
"amount": "100.500000"
}