Secret keys vs. publishable keys, in plain terms

Your booking system uses two different kinds of keys, for two different jobs. Using the right one in the right place is the single most important safety habit for your integration.

Secret key

This key lives only on your website’s own server — the part of your website your developer or agency controls, never the part a visitor’s browser can see. It can do everything we’ve allowed for your account: read a guest’s name and email, create and cancel bookings, change your rates and prices.

Because it can do so much, it must never leave your server. Never put it in a browser, a mobile app, a public code repository, or a chat message.

Publishable key

This key is meant to be seen — it’s built into the small booking widget script that runs in a guest’s browser on your public website. Anyone who looks at your page’s source code can find it, and that’s fine by design.

It can only do three things: check availability, get a price, and start a hold. It can never read a guest’s name or email, and it can never move money or complete a booking on its own — even someone who copies this key straight off your page can’t do anything more with it than a normal visitor already could.

Why this split matters to you

This is what makes it safe to run our booking widget on your own website without needing your own security team. The key a visitor can see is deliberately limited to almost nothing; the key that can actually do anything sensitive never leaves your server.

If you’re not sure which one you need

If your developer or agency asks for “an API key” without saying which kind, ask them where it’s going:

• Going into your website’s server code, somewhere a visitor’s browser never sees it? That’s a secret key.
• Going into the booking widget snippet on your public page? That’s a publishable key.

If you’re still unsure, ask us before sending either one — it’s a normal question, not an inconvenience.