List Registered Wallets (Merchant)

​

GET /v2/merchant/wallet/registered

​

Authentication

​

Query parameters

​

Example

curl "https://apiv3.droplinked.com/v2/merchant/wallet/registered" \
  -H "Authorization: Bearer <MERCHANT_JWT>"

​

Response — 200 OK

{
  "wallets": [
    {
      "walletAddress": "0xB2721aD4F1c4dD8fE45F3F3c8e4F8c8c5d5f1eA9",
      "network": "base",
      "label": "Mainnet Treasury",
      "isPrimary": true,
      "claimedAt": "2026-06-14T17:30:00.000Z",
      "lastVerifiedAt": "2026-06-14T17:31:00.000Z"
    }
  ],
  "asOf": "2026-06-14T17:31:05.220Z"
}

​

Fields

​

Errors

​

Notes

• Caching. The response carries Cache-Control: private, max-age=30. Clients should expect up to a 30s lag after a claim / deregister before the change is visible if the response was cached by an intermediate.
• Auth scope. The endpoint reads merchantId from the JWT sub claim only. Any ?merchantId= query parameter is silently ignored. A merchant cannot read another merchant’s wallets through this endpoint.
• Ordering. Rows are sorted by claimedAt descending — most-recently claimed first. Primary status does not affect order; check isPrimary to identify the routed-to wallet.
• Fail-open semantics. If the underlying read throws, the endpoint returns the empty-state envelope (wallets: []) with 200 OK rather than propagating the error. Inspect server logs / Sentry for the underlying failure. Merchants never see a partial Wallets-panel error in the dashboard.
• Across networks. The list is not filtered by network. A merchant registered on base today and a future second network tomorrow will see both rows here; clients filter client-side as needed.

​

Related

• Register Settlement Wallet — POST counterpart that creates / re-verifies an entry in this list.
• Deregister Wallet — removes a row from this list.
• x402 Earnings (Merchant) — per-merchant rollup of settlement events that route to the primary wallet.