Authentication & access
One platform, two caller identities, and a clear boundary between them.
On this page
Choose the right credential
| Surface | Credential | Who it represents |
|---|---|---|
| Visa Intelligence | Server-side API key | The integrating tenant |
| Tenant API | Server-side API key | The integrating tenant |
| Traveler API | Customer Bearer token | A signed-in person with explicit resource access |
| Authentication | Depends on the operation | An integration, a sign-in challenge, or a managed session |
Keep your login or use ours
Use your existing login when your backend already authenticates customers. It exchanges the authenticated user’s stable subject for a Wincora customer session. The API key stays on your server.
Use Wincora customer authentication when you need passwordless sign-in inside your own interface. A registered application starts a challenge, verifies a one-time code, and receives the same type of customer session.
Use your existing loginSeparate accounts, identities, and travelers
A person may act for themselves, a dependent, or explicitly assigned employees. Membership in a corporate customer account does not reveal every traveler in that company. Email addresses are contact details, not identity keys.
| Concept | Meaning |
|---|---|
| Customer account | The personal or corporate commercial account. |
| Customer identity | The person authenticated in your application. |
| Traveler | The person whose application is being processed. |
Provision access before issuing sessions
Create customer identities and their resource relationships through separately permissioned Tenant endpoints. Session creation consumes those relationships; it cannot create or widen them.
Effective access is the intersection of the integration delegation policy, current identity relationships, requested scopes, tenant entitlements, and business rules. An intelligence-only key cannot issue sessions.
Customer identities and accessKeep integration keys on your server
Tenant and Intelligence calls use X-Api-Key over HTTPS. Credentials are tenant- and environment-bound, with explicit grants and integration-owned, selected-customer, or tenant-wide resource policies. Use separate keys for customer-session issuance and privileged staff operations.
API keys support show-once secrets, expiry, rotation, and revocation. Rotation preserves the integration identity. A key cannot grant itself access or mint other integration keys.
Customer tokens are restricted to Traveler
Send Authorization: Bearer with the Wincora-issued customer token. Its audience is the Traveler API for the selected environment. It cannot call Tenant or Visa Intelligence routes, even on the same hostname.
Access tokens expire after five minutes. Each request also checks current session status and resource relationships. Revoking a session or removing access blocks subsequent requests. Do not store tokens in URLs, browser persistent storage, logs, or analytics.
Interpret access failures
| Status | Meaning |
|---|---|
| 401 | Missing, expired, revoked, or invalid credential, including the wrong token audience. |
| 403 | An authenticated caller lacks the required permission. |
| 404 | A resource is missing or outside the permitted resource set. |