Start with the Otto Wallet API
This route is for teams that want direct backend control over signing, retries, and wallet orchestration while staying on the same public contract used by the SDK.
The API and SDK share the same contract
Use the API directly when you want explicit ownership of HTTP calls. Use the SDK when you want the same public contract with signing already wrapped. The resources are the same: vaults, wallets, transactions, gas station, MPC, and webhooks.
Generate workspace credentials in the dashboard
Every public integration starts with a workspace-issued API key and secret. The key identifies the caller. The secret signs the request payload.
X-API-Key · X-SignatureX-API-Key: test_xxx X-Signature: <base64 hmac sha256> Content-Type: application/json
Sign the canonical payload on the server
Otto verifies the signature against the serialized JSON body. That means your backend, worker, or secure server runtime should be the only place where the secret exists.
@ottowallets/sdk.Create a vault, then generate a wallet under it
/vault/create → /wallet/generate-address-hdCreate vault body
| Name | Type | Required | Description |
|---|---|---|---|
| name | string | Yes | Human-readable treasury name. |
Generate wallet body
| Name | Type | Required | Description |
|---|---|---|---|
| network | string | Yes | Network slug like ethereum. |
| vault_id | string | Yes | Vault identifier returned by the previous call. |
| name | string | No | Optional display label for the managed wallet. |
Preview first, then execute under policy
The safe pattern is to preview a transfer, validate fee and readiness, then submit the execution request. Authentication proves identity, but policy still decides what can actually run.
/wallet/transfer-preview{
"from": "0xSender",
"to": "0xReceiver",
"amount": "0.50",
"tokenAddress": null
}403 usually means roles, policies, assignments, or environment scope denied the action, not just a missing credential.