API Reference
Choose the correct DEUNA API surface, authorization model, and caller for each integration flow.
On this page
DEUNA exposes public API surfaces for merchant backends, customer applications, partners, and provider callbacks. Start with the caller—not only the resource name—because the supported authorization model changes by surface. Internal Admin and management APIs are intentionally excluded.
Use the complete endpoint catalog to search every configured API Gateway operation by intended consumer, owning service, authorization, or header.
Base URLs#
Use the sandbox base URL while you build. Switch to production only after receiving production credentials and completing certification.
Choose the API surface#
| Surface | Intended caller | Authorization | Use it for |
|---|---|---|---|
| Merchant backend · server to server | Trusted merchant infrastructure | Private API key in X-Api-Key; X-Store-Code and idempotency headers where required | Orders, purchases, captures, refunds, voids, consent and operational reads |
| Customer application · user to server | Merchant Web or mobile application acting for a customer | Public application context plus user Authorization: Bearer … after login; never embed a private key | Login, profile, addresses, stored cards and customer-authorized wallet flows |
| Network or partner backend | Approved network or platform integration | Partner credentials and tenant/network context defined during onboarding | Network-scoped orders, configuration and reporting |
| Provider callback · provider to DEUNA | Payment, fraud, wallet or platform provider | Provider-specific callback contract; the Gateway forwards callback headers to the owning service and does not declare a shared credential validator | Asynchronous status notifications; merchant systems must not call these routes |
Authentication#
Merchant backend
Send the private API key in X-Api-Key, not in the Bearer header. Keep it on trusted server infrastructure.
X-Api-Key: YOUR_PRIVATE_API_KEY
X-Store-Code: STORE_CODE
X-Idempotency-Key: order_1042-attempt_1
Content-Type: application/jsonAuthenticated customer
Send the user access token in the Bearer header. Some order and wallet operations also require the merchant application key or store context; the endpoint catalog shows the authorization and forwarded headers for each route.
Authorization: Bearer USER_ACCESS_TOKEN
X-Api-Key: APPLICATION_API_KEY
X-Store-Code: STORE_CODE
Content-Type: application/jsonPartners
Partner credentials and network context are provisioned during onboarding. Do not substitute a checkout private API key for a partner credential.
See Authentication for credential handling, token lifetimes and rotation.
Merchant backend operations#
Customer application operations#
Provider callbacks#
Provider callback routes are part of the complete inventory so teams can identify ownership and avoid calling them accidentally. They are not merchant webhooks. To receive DEUNA events in your own backend, configure the order webhook URL and follow Webhooks.
Responses and errors#
Browse the complete list in Error codes.
Path versioning#
Use each path exactly as published. API Gateway frequently exposes canonical routes without an internal /api/v1 prefix. A version segment such as /v2 is included only when it is part of the public route shown in the catalog. Backwards-compatible changes are listed in the Changelog.