Static wallets

Use it where funding an account is a core feature — player balances, trading accounts, prepaid services. For one-off fixed-amount charges, use Payments instead.

Create a wallet per customer

curl -X POST https://api.suward.com/v1/static-wallets \
  -H "X-Api-Key: $SUWARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "externalId": "customer-99",
    "allowedAssets": ["USDT_ETHEREUM", "USDT_ARBITRUM"]
  }'

• allowedAssets is the wallet's accept-list. A deposit in any other asset is recorded with status ignored — visible for audit, never credited. Update the list any time with PATCH /v1/static-wallets/{staticWalletId}.
• externalId is your customer reference: creation is idempotent by it (retries never create a duplicate wallet), and it is denormalized onto every deposit, so a webhook alone tells you whose money arrived.
• Optional: a per-wallet webhookUrl override and arbitrary metadata.

The response returns the wallet's address — hand it to the customer once; it stays theirs.

{
  "id": "sw_71b0d4",
  "projectId": "prj_1a2b",
  "address": "0x7c31…be04",
  "allowedAssets": ["USDT_ETHEREUM", "USDT_ARBITRUM"],
  "externalId": "customer-99",
  "createdAt": 1769000000000,
  "updatedAt": 1769000000000
}

Deposits: the lifecycle

Each incoming transfer is recorded as an individual deposit and moves through detected → accepted → confirmed as finality accrues; a chain reorganization rolls an unfinalized deposit back to invalidated. Credit your user at accepted (a static_deposit.accepted webhook fires), treat the funds as final at confirmed / static_deposit.success. Deposits that fail screening are held (complianceHold) or rejected (complianceRejected, which sends static_deposit.failed) before crediting. → Settlement & finality, Screening levels

Every deposit records amount, fee, networkFee, and netAmount, plus txHash and transferIndex — enough to reconcile a single transfer inside a batched transaction. List them with GET /v1/static-wallets/{staticWalletId}/deposits, or fetch one by id.

curl "https://api.suward.com/v1/static-wallets/sw_71b0d4/deposits?limit=20" \
  -H "X-Api-Key: $SUWARD_API_KEY"

Operate at scale

• Addresses don't expire; there is nothing to refresh or reissue.
• Deleting a wallet stops monitoring its address for new deposits; recorded deposits are unaffected.
• Funds land on the same project balance as payments; sweep them with Auto-withdrawals.
• Listing is cursor-paginated: limit up to 100, lastId from the previous page, order asc or desc.

Test it

Drive a synthetic deposit through its lifecycle with POST /v1/static-wallets/{staticWalletId}/simulate (test assets only; no chain activity, no balance credit), or send real test tokens to the address and watch the full pipeline run. → Test payments

curl -X POST https://api.suward.com/v1/static-wallets/sw_71b0d4/simulate \
  -H "X-Api-Key: $SUWARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "asset": "TESTSTABLECOIN_OPTIMISM",
    "amount": "25000000",
    "status": "accepted"
  }'

Next: Auto-withdrawals for treasury rules · Webhooks for crediting your users automatically.