Authentication Overview

VanityPass APIs support two distinct authentication modes: B2B server-to-server via API key, and white-label end-user via JWT + app context.

B2B (Server-to-Server)

B2B integrations authenticate using an X-Api-Key header. This mode is designed for backend-to-backend communication where your server holds the API key securely and makes requests on behalf of your users.

Header: X-Api-Key: vp_live_... or vp_test_... (sandbox)

Use case: Your booking engine calling VanityPass to search flights, make reservations, check perk availability, or manage organizations.

Security: Keep your API key in environment variables. Never expose it in frontend code or public repositories.

White-label (End-User Apps)

White-label integrations authenticate using a JWT token plus X-App-Id or X-App-Slug header. This mode is for user-facing applications (mobile apps, web portals) where each user has their own JWT.

Headers:

• Authorization: Bearer <JWT>
• X-App-Id: <app-uuid> or X-App-Slug: <app-slug>

Use case: A user logs into your app, receives a JWT, and makes requests directly from their device.

Security: JWTs are typically short-lived (1 hour) and include user identity + scoped permissions. X-App-Id/Slug identifies the white-label app context.

Sandbox Playground

This documentation site includes an interactive "Try it" playground embedded in every endpoint page. The playground is sandbox-only — all requests are routed to https://cloud.vanitypass.com with X-Environment: Sandbox header. No real transactions occur.

Key points:

• Credentials are stored in your browser's sessionStorage (or localStorage if you choose "Remember").
• Credentials never leave your browser.
• All traffic is CORS-safe and sent only to the sandbox endpoint.
• For production access or API keys, contact the sales team.

Next Steps

• Read Environments to understand sandbox vs production.
• Check Errors for API error format.
• Explore the endpoint pages for your use case (B2B or white-label).