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.
/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.
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.