Developers · Bots

Run deposit automation without inventing a rate manager.

A bot integration is not a browser flow with the buttons removed. It needs duplicate prevention, restart-safe state, explicit wallet custody, webhook verification, and a clear rule for when liquidity should be private.

01

Bot sequence

  1. 1Load a Base wallet client from your own signer infrastructure.
  2. 2Call deposits(walletAddress) before creating a new deposit; reuse active inventory when it fits the order.
  3. 3Call offramp(walletClient, params) with integratorId and referralId so automation can be identified.
  4. 4Use otcTaker when the buyer is already known; otherwise the deposit is public fillable.
  5. 5Persist depositId, txHash, platform, currency, amount, and intended buyer context.
  6. 6Register HMAC webhooks so fills and closes survive process restarts.
02

Retry discipline

  • The SDK resumes undelegated deposits by delegating instead of creating a duplicate.
  • Browser idempotencyKey caching does not protect Node workers. Your worker should check deposits(address) before creating new liquidity.
  • If delegation fails after creation, retry the same wallet route; the resume path is designed for that state.
  • Do not retry USER_CANCELLED automatically. That indicates a signer rejected a prompt.

Common questions

Can a backend create deposits without a user wallet?

Yes, if it has its own Base signer and USDC balance. The SDK signs through the viem WalletClient you provide; custody and key management are yours.

Does idempotencyKey prevent duplicate bot deposits?

No. idempotencyKey is browser-session backed. In Node or workers, use deposits(address) and your own order database to prevent duplicate inventory.