Authentication boundaries
JWT & other auth routes
Understand what merchant API tokens deliberately cannot do, when an interactive JWT is required, and where Vouchify uses entirely separate credentials.
JWT and API token are not interchangeable
| Property | Interactive JWT | Merchant API token |
|---|---|---|
| Represents | A signed-in user session | A merchant-owned integration |
| Created through | OTP or OAuth authentication | JWT-only management API |
| Best for | Sensitive user-driven operations | Scoped server-to-server business operations |
| Scope metadata | Bypasses API-token scope checks | Must satisfy explicit route policy |
| Shared enforcement | Live role, merchant, ownership, status, and existing permission checks still apply. | |
| Token management | Allowed for active merchant owner | Rejected |
Token management begins with email + OTP
API.md classifies OTP and token management as JWT-only but does not publish OTP paths or schemas. The token console uses this verified account-authentication contract:
POST /auth/otp/send
Content-Type: application/json
{
"email": "dev.user@vouchify.local",
"name": "Dev User",
"requestFrom": "user-app"
}POST /auth/otp/verify
Content-Type: application/json
{
"email": "dev.user@vouchify.local",
"code": "123456"
}The verification response returns interactive access and refresh tokens. This docs console keeps the access token in memory only and does not persist the refresh token.
/api-tokensList active, revoked, and logically expired token records./api-tokens/scopesRead the complete server-defined scope catalog and explicit preset expansions./api-tokensCreate a merchant-owned API token in the first available slot./api-tokens/:idUpdate an active token's name, explicit scopes, or expiration policy./api-tokens/:id/rotateAtomically replace the secret while preserving token policy and slot./api-tokens/:id/revokeIrreversibly and idempotently revoke a token, with an optional bounded reason./api-tokens/:idPermanently delete an inactive record and free its slot.JWT-only route categories
These are intentionally excluded from merchant API tokens because they change identity, ownership, money movement, sensitive verification state, or the integration credentials themselves.
01Authentication and account securityJWT only
Interactive identity and credential administration do not accept merchant API tokens.
- OTP send, merchant signup OTP, and OTP verification
- Google and Apple OAuth flows
- Refresh token
- Logout and logout-all
- Account profile and security operations
- API-token management routes
02Financial and payment operationsJWT only
API-token wallet support is read-only, and voucher decryption is deliberately excluded.
- Billing subscription changes, invoice payments, payment verification, and cancellation
- Wallet withdrawals, deposits, transfers, and payment requests
- User voucher purchase, activation, extension, top-up, cashout, sharing payments, and card or mobile-money flows
- User membership purchase, renewal, sharing payments, and payment completion
- Voucher decryption
03Team and ownership operationsJWT only
Ownership, invitation, and privileged team mutations require interactive JWT authentication.
- Team invitations
- Team role changes
- Team member removal
- Invite acceptance
- Merchant ownership claims and ownership-code verification
- Merchant-group creation, requests, settings mutations, and group membership mutations
- Admin and delegator-only routes
04KYB and identity operationsJWT only
Merchant API tokens expose only the two documented KYB read routes.
- KYB field changes
- KYB document upload and submission
- Identity-document uploads
- KYB completion and document proxy operations
05Widget key managementJWT only
JWT owner routes derive the merchant from CurrentUser and reject arbitrary body merchantId selection.
- Widget-key creation
- Widget-key detail
- Widget-key deletion
Separate authentication contracts
Widget API
Widget routes use x-public-key with WidgetApiKeyGuard, not merchant bearer tokens.
- Widget checkout
- Widget reads
Callbacks and verification links
Callbacks retain callback authentication and verification links retain dedicated link credentials.
- pawaPay callbacks
- Apple Wallet callbacks
- Withdrawal verification links
x-public-key, callback authentication, or a dedicated verification-link credential.