Loading
API access
One account, two API contracts, and a live inventory of tours, attraction tickets, transfers, rentals and multi-day trips across 38 product types. No access fee, and a sandbox that books the real catalogue so you are testing what you ship.
Read the docs before you apply if you want to. Both references are open and complete, including request and response shapes for every endpoint. Nothing is behind the form except the credentials themselves.
What you get
Six things that are worth knowing before you decide whether this is a week of work or an afternoon.
OCTO if you are building fresh or have integrated an OCTO supplier before. Distribution v2 if you already consume a BeMyGuest-shaped API and would rather repoint a base URL than rewrite a client. Same products, same rates, same availability behind both.
Not a nightly export. The capacity you read is the operator's actual remaining capacity, decremented the moment anyone anywhere books, so you cannot sell a seat that is gone.
Reserve holds the seat and the funds while you take payment from your own customer. Confirm captures. An abandoned checkout expires on its own and costs you nothing, so you never carry inventory risk.
Integer minor units with explicit precision, never floats. Every price carries what you pay and the published retail price separately, and the FX rate is frozen onto the booking so a total never drifts after the fact.
Everything is held in USD and converted at the boundary from rates refreshed hourly. Ask for prices in the currency your customer thinks in and stop maintaining a conversion table.
Cancellation ladders and voucher validity arrive structured, so your own system can display and enforce them rather than rendering a paragraph nobody reads.
Onboarding
Six steps. Most of the elapsed time is us reading your application; most of the work is the two calls in the middle.
The form below. Tell us what you are building, because it decides which contract we point you at.
A person reads every application, usually within one business day. We are checking that there is a real integration behind it, not gatekeeping for its own sake.
Sign in, open API keys, and issue one. The secret is shown once, so store it before you navigate away.
List products with your key. If that returns JSON, authentication is done and everything else is data modelling.
Reserve with your sandbox key, then let it lapse. The hold and the release are real, the booking is flagged as a test, and nothing reaches an operator.
Issue a production key alongside your sandbox one. Same URLs and payloads; only the credential changes.
Prove authentication before you build anything on top of it. If this returns a list of products, the rest of the integration is data modelling rather than plumbing.
curl https://api.vacotours.com/octo/products \
-H "Authorization: Bearer YOUR_KEY.YOUR_SECRET" \
-H "Octo-Capabilities: octo/pricing, octo/content"The capabilities header is how OCTO keeps payloads small: ask for what you can render and nothing else arrives. Leave it off entirely and you get the core shape, which is enough to start.
Questions
No. There is no access fee, no monthly minimum and no per-call charge. We make money on commission inside the rates you book at, and that rate is the same in the panel as it is over the API.
Yes, and it is not a separate copy of the system. You issue a sandbox key and it books the real catalogue, so the code path you exercise is the one you ship. Bookings made with it are flagged as tests and never reach an operator's manifest or settlement. They are paid from a separate sandbox wallet of play money, refilled automatically, so your real balance is never touched. They do hold real seats, so let reservations expire rather than leaving confirmed tests sitting on a live departure.
Usually within one business day. We read the application rather than pattern-matching it, so a sentence about what you are building genuinely speeds this up.
OCTO unless you already consume a BeMyGuest-shaped API, in which case v2 will be less work. Both reference docs are open and you can read them before applying.
You need to be able to sell what you book, which in practice means an agency, an OTA, a hotel concierge system, a corporate travel tool or something similar. Individual developers building a portfolio piece are better served reading the docs, which are public.
No. Content and availability are served to buyers who book, because operators are exposing live capacity rather than a catalogue.
You swap the sandbox key for a production one, and nothing else changes. Same base URL, same payloads, same behaviour, because both keys run against the same system.
If you run the experiences rather than resell them, you want the supplier API, which pushes inventory rather than consuming it.
One form. A person reads it, usually within a business day, and your credentials appear under API keys in the panel.