Copy page

Webhooks

Treasury Updates

Deposit Events

Event	Fired when
deposit.quote_created	Route planning is complete; execution steps are created with exchange rate info
deposit.updated	General notification that a field on the deposit has been updated
deposit.expired	The deposit reached its expiration date-time and is no longer actively processing

Withdrawal Events

Event	Fired when
withdrawal.quote_created	Route planning is complete; execution steps are created with exchange rate info
withdrawal.balance_updated	Balance check result is available (reserved or awaiting_funds)
withdrawal.updated	General notification that a field on the withdrawal has been updated
withdrawal.expired	The withdrawal reached its expiration date-time and is no longer actively processing

Rebalance Events

Event	Fired when
rebalance.quote_created	Route planning is complete; execution steps are created with exchange rate info
rebalance.balance_updated	Balance check result is available (reserved or awaiting_funds)
rebalance.updated	General notification that a field on the rebalance has been updated
rebalance.expired	The rebalance reached its expiration date-time and is no longer actively processing

Step Events

All other lifecycle updates for a deposit, withdrawal, or rebalance fire at the step level as each step progresses:

Event	Fired when
step.signature_requested	Tesser has prepared an unsigned transaction and is waiting for your signature. The payload carries it as unsigned_transaction
step.signed	Step has been cryptographically signed
step.submitted	Step has been submitted for execution
step.confirmed	Step execution is confirmed on-chain or by the partner
step.completed	Step finished successfully
step.failed	Step encountered an error and could not complete
step.updated	General notification that a field on the step has been updated

The data.object for step events is a DepositStep, WithdrawalStep, or RebalanceStep, depending on the resource the step belongs to. The three differ in three ways only:

• The parent-resource id — deposit_id, withdrawal_id, or rebalance_id.
• unsigned_transaction — defined on withdrawal and rebalance steps; deposit steps have no such field. Where it exists it is populated only while a step your organization signs is sitting in signature_requested status; on every other step and status it is null.
• provider_key — circle_mint, openfx, or turnkey on deposit and withdrawal steps, but only circle_mint or turnkey on rebalance steps. A rebalance moves funds between your own accounts, so it never routes through a liquidity provider.

Signing applies only to steps your organization signs — on-chain steps out of a self-custodial wallet, where provider_key is turnkey. Deposits are never signed by you, so step.signature_requested and step.signed do not fire on a deposit. To sign a withdrawal or rebalance step, see Sign a Wallet Step.

Expiration

When a deposit, withdrawal, or rebalance reaches expires_at before completing, its unfinished steps are resolved and two kinds of event fire:

• step.failed, one per step still in created or signature_requested — the only two statuses expiration fails. Each carries failed_at and a status_reasons entry with error_code transfers-9204 ("The transfer expired before it could be executed"). A step that has reached signed, submitted, or confirmed is in flight on-chain, so expiration leaves it to resolve on its own outcome instead of failing it.
• <resource>.expired — deposit.expired, withdrawal.expired, or rebalance.expired — carrying the final state of the resource.

No <resource>.updated follows <resource>.expired — the expiration event itself carries the final top-level values, including whatever the actual overlay settled to. Steps never emit an event of their own for expiration; it is a property of the parent resource, and a failed step's outcome surfaces as step.failed.

For how the resource's fields look at expiration, see Expiration.

Payload

The data.object for each top-level Treasury event contains the full resource. See General for the envelope shape and example payloads, and the Deposit schema, Withdrawal schema, and Rebalance schema for the full field reference.

Unlike payments, Treasury resources carry no compliance arrays — there is no risk_status, risk_status_reasons[], participants[], or provider_metadata[] on a deposit, withdrawal, or rebalance. Withdrawals and rebalances do carry balance_status; deposits do not.