Skip to main content
Users fund their account by depositing supported tokens on-chain, and can withdraw them again. Both are asynchronous: start them through the API, then confirm the result with webhook events and the resource’s status.
The account must be active with a safe_address before you accept deposits or create withdrawals. See Onboard a user.

​
Accept deposits

1

Get the supported tokens

Call GET /accounts/{account_id}/available-tokens before showing any deposit options. Only offer the tokens this returns.
2

Show the deposit address

Read the deposit address from the account’s funding configuration, under funding.config. Show it together with the chain the account is configured for.
3

Tell the user what to send

Ask the user to send only a supported token, and only on the configured chain. Make this clear in your UI. Tokens sent on the wrong chain, or unsupported tokens, may not be credited.
4

Listen for events

Listen for deposit and balance webhook events.
5

Reconcile

Confirm the deposit with GET /deposits/{deposit_id} and the account balance with GET /accounts/{account_id}/balances.
Don’t make funds spendable based on a transaction hash alone. Rely on the deposit status and the current account balance.

​
Create a withdrawal

1

Check the available amount

Call GET /accounts/{account_id}/balances. Use the token’s max_instant_withdraw as the most the user can withdraw, and don’t let them enter more.
2

Create the withdrawal

Call POST /withdrawals with the account, the token contract address, and the amount in the token’s base units.
3

Store the withdrawal ID

Store the returned withdrawal_id against your user record.
4

Track the result

Listen for withdrawal webhook events, and confirm the final state with GET /withdrawals/{withdrawal_id}.
Token amounts are strings paired with a decimals value. Convert between display amounts and base units with a decimal or big-integer library, never with floating-point numbers. For example, 25 USDC with 6 decimals is "25000000".

​
Build account activity

The Partner API exposes each activity type as its own resource. There is no combined account-statement endpoint. List each resource with the same account_id: Page through each collection independently. If your product needs one timeline, merge the results in your backend and sort them by created_at. Don’t share a pagination cursor between resources. Card transaction items represent changing payment lifecycles rather than raw card-network events. Read Read card transactions before mapping their status and amounts.billing and amounts.merchant fields.
Before any deposit, withdrawal, balance, or activity call, check that the account_id belongs to the user making the request.