Skip to main content
The Public API is Voyant’s customer-facing surface. It is the discovery and booking experience a traveler interacts with: browsing the catalog, viewing a product or departure, previewing prices, and moving through a booking session to checkout. It is a first-class part of the platform rather than a loose collection of public routes. The contract is owned by the platform, while the frontend that consumes it is owned by you, so you control branding, layout, and UX while building on a stable public contract.

What the Public API covers

  • Catalog browsing across owned and sourced inventory.
  • Departure and product detail pages.
  • Pricing preview and sellability resolution.
  • Booking-session flows that lead to checkout.
  • Customer-facing itinerary reads and self-service.

The boundary

The HTTP transport draws a clear line between staff and customer surfaces:
  • /v1/admin/* serves staff and operator surfaces.
  • /v1/public/* serves external, customer-facing surfaces.
Public contracts are kept separate from admin CRUD semantics: the public surface exposes only what a customer should see and do, with its own request and response shapes, rather than reusing internal admin endpoints. /v1/public is a union rather than a single module’s namespace. Invitations mount there from auth; proposals and bookings from trips; and charters, operator profile, operator settings, payment-link config and travel-credit validation each mount from their own module. Whatever owns the name does not own every route — so if you are looking for a charter route, do not conclude it is missing because it is not in the Public API package.

Keys

Access is by key, and a key carries its own allowed origins:
  • vpk_ publishable — ships in a browser bundle. It is origin-bound, because the declared-origin check is the only thing narrowing where it may be used.
  • vsk_ secret — server-only. A genuine server-to-server caller has no browser origin to send, so no origin is required.
A key resolves to a sales channel. Left unset it resolves to your Direct channel, which is everything you sell through yourself — whoever built the frontend. A key may name a different channel so affiliate, reseller and API-partner arrangements keep working.

Packages

To build a custom frontend against the public contract, install @voyant-travel/storefront-sdk. Its name predates this surface being called the Public API; it is the same contract and remains the published SDK. @voyant-travel/public-api-contracts carries the customer-portal request and response shapes, so you can validate /v1/public/customer-portal payloads in a browser without the server. The catalog projection that powers discovery is produced by the catalog module and can be enriched with Connect sourced inventory.