Authentication

Every request needs your key as a Bearer token:

Authorization: Bearer sk_live_...

No other credentials. The key identifies your organization, and every request is scoped to it, you only ever see your own packages and bookings.

Test vs live keys

Your organization has two kinds of key. Both are sent the same way and use the same base URL. The prefix (sk_test_ or sk_live_) decides what the key is allowed to do.

Use a test key while you build. It can do everything except create or change a booking. So you can wire up and validate your whole integration (search packages, check availability, price a change) with zero risk of a real booking or a real charge.

Switch to a live key for real bookings. Generate one, swap it into your config, and you're done. Same base URL, same requests, real bookings.

When a test key attempts something it can't, the API returns 403 with "code": "TEST_KEY_NOT_ALLOWED". That's your cue to switch to a live key.

Test and live keys are independent: generating or rotating one never affects the other, and each has its own rotate and revoke.

Rotating a key

Rotate from Developers → API Key → Rotate when a key might be exposed, or on a schedule.

• You get a new key. The old one keeps working for 24 hours, then stops.
• That grace window lets you roll out the new key with no downtime.
• Revoke kills a key immediately, no grace. Use it if a key leaks.

Security

• Keys are stored hashed. We can't show you a key again after you create it. Lost it? Rotate.
• Org-scoped. Another organization's package or booking returns 404.
• Server-side only. Keep the key on your backend. If your app needs the data, proxy through your own server so the key never reaches the client.

Auth errors