Migrate to the VaaS Endpoints
Move your integration from the deprecated /api/v1/virtual-account endpoints to the VaaS endpoints under /api/v1/vaas.
The virtual account endpoints under /api/v1/virtual-account are deprecated. They keep working for existing integrations, but they are no longer maintained and won't receive updates or fixes. Use the VaaS endpoints under /api/v1/vaas for new integrations, and move existing integrations to them.
What changes
Mostly the path. Every legacy endpoint has a VaaS equivalent, and all but one sit at the same path with virtual-account replaced by vaas. The exception is reactivating an expired account, which moves to POST /api/v1/vaas/update-virtual-account and takes the account reference in the request body instead of the path:
| Operation | Legacy endpoint | VaaS endpoint |
|---|---|---|
| List virtual accounts | GET /api/v1/virtual-account | GET /api/v1/vaas |
| Create a virtual account | POST /api/v1/virtual-account | POST /api/v1/vaas |
| Get a virtual account | GET /api/v1/virtual-account/find | GET /api/v1/vaas/find |
| Reactivate an expired virtual account | POST /api/v1/virtual-account/update-by-reference/{reference} | POST /api/v1/vaas/update-virtual-account |
| List a virtual account's transactions | GET /api/v1/virtual-account/find-by-reference/{reference}/transactions | GET /api/v1/vaas/find-by-reference/{reference}/transactions |
VaaS also adds endpoints to activate and deactivate a virtual account, which have no legacy equivalent.
What stays the same
- Requests: the same body fields, query parameters and validation rules, apart from
referencemoving into the body when you reactivate an account. - Responses: the same response format and fields.
- Authentication: the same API keys and headers.
- Webhooks: deposits into a virtual account send the same webhooks, whichever endpoint created the account.
- Your existing virtual accounts: accounts you created through the legacy endpoints are available through the VaaS endpoints with the same
referenceandsource_reference. You don't need to recreate them.
One difference in behaviour
When you reactivate an expired single_use account through VaaS, Atlas treats the renewed account as unpaid, so its next payment marks it as used, the same as a new account. Through the legacy endpoint, a reactivated account can stay active after it's paid again.
How to migrate
- Replace
/api/v1/virtual-accountwith/api/v1/vaasin every request your integration makes. For reactivation, call/api/v1/vaas/update-virtual-accountand sendreferencein the body. - Run your integration against Atlas in test mode and confirm each request behaves as before.
- Deploy the change with your live API keys.
For example, creating a virtual account changes from:
curl -X POST "https://atlas.tryduplo.com/api/v1/virtual-account" \
-H "Authorization: Bearer your_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"account_type": "multi_use",
"account_name": "Acme Store",
"source_reference": "src_1234567890"
}'to:
curl -X POST "https://atlas.tryduplo.com/api/v1/vaas" \
-H "Authorization: Bearer your_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"account_type": "multi_use",
"account_name": "Acme Store",
"source_reference": "src_1234567890"
}'For the full request and response details, see the virtual accounts guide.
How is this guide?
Last updated on