Obtain an OAuth access token by POSTing to the token endpoint with your sandbox client_id and client_secret and grant_type=client_credentials.
Create a verified or unverified customer by POSTing to /v2/customers with the required fields (firstName, lastName, email, and for verified customers, address and date of birth); record the customer resource URL from the Location header.
Add a bank funding source to the customer by POSTing to /v2/customers/{id}/funding-sources with routing number, account number, bankAccountType, and a name; receive the funding source URL.
Verify the funding source using micro-deposits or instant verification (Plaid/Dwolla IAV) before it can be used for transfers.
Initiate a transfer by POSTing to /v2/transfers with _links for source and destination funding sources, the amount object (value and currency), and an idempotency-key header.
Poll GET /v2/transfers/{id} or subscribe to Dwolla webhooks (transfer_completed, transfer_failed) to track the transfer to a terminal status.
Known gotchas
Unverified customers have a $5,000 weekly transfer limit and cannot hold a Dwolla balance; if your use case requires higher limits or a balance, you must create a verified customer with full KYC.
Sandbox ACH transfers do not follow real banking schedules — you can simulate completions and failures using Dwolla's sandbox simulation endpoints, but production transfers follow actual ACH processing windows.
Idempotency keys must be unique per request attempt; reusing a key for a different transfer will return the original transfer response, which can cause silent double-payment bugs if your key generation is not tied to your internal transfer ID.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp