Authentication

Every request to the CampOne API must be authenticated with a tenant-scoped API key. There is no user-level OAuth flow — keys belong to the tenant, not to an individual operator.

Token format

A raw API key is a 32-character string with a fixed shape:

ck_<8-char visible prefix><24-char secret>

A complete example (do not use this — it is illustrative):

ck_a1b2c3d4XXXXXXXXXXXXXXXXXXXXXXXX

The first 8 characters (ck_a1b2c3 in the example) are the visible prefix. The platform stores this prefix in clear text so the operator can identify a key in the admin console without seeing the secret. The remaining 24 characters are the secret suffix, which is hashed at rest and never recoverable. The full 32-character string is what you send on every request.

Authorization header

Send the full token on the Authorization header using the Bearer scheme:

GET /api/v1/public/bookings/ HTTP/1.1
Host: api.campone.ch
Authorization: Bearer ck_a1b2c3d4XXXXXXXXXXXXXXXXXXXXXXXX
Accept: application/json

A complete curl example:

curl https://api.campone.ch/api/v1/public/bookings/ \
  -H "Authorization: Bearer ck_a1b2c3d4XXXXXXXXXXXXXXXXXXXXXXXX" \
  -H "Accept: application/json"

The token determines both which tenant the request operates against and what it is allowed to do. There is no separate tenant header.

How to get a key

API keys are issued from the admin console by a tenant administrator under Settings → API. The admin enters a human-readable name (e.g. “Booking.com sync”), picks the scopes the integration needs, and optionally sets an expiry. The platform displays the raw token exactly once at the moment of creation — copy it into your secret store immediately. If you lose it, you have to generate a new one.

If your tenant has not yet enabled the API module, contact your CampOne representative to have a key issued.

Scopes

Each key carries a list of scope strings. The endpoint you call requires one of them; if the scope is missing the call returns 403. The available scopes are:

Scope	Grants
bookings:read	List + detail bookings
bookings:write	Create bookings
sites:read	List sites
customers:read	List customers
invoices:read	List invoices

A key can hold any subset of these. Request the minimum your integration actually needs — a channel manager that only pushes new reservations does not need customers:read.

Key lifecycle

Creation. A key is active immediately after generation and starts being accepted on the next request.

Expiry. If the operator set an expiry at creation time, the key stops working at that timestamp. Requests with an expired key return 401 key_inactive. There is no automatic renewal — you have to generate a new key before the old one expires.

Deactivation / revocation. An admin can revoke a key from the same Settings → API screen. Revoked keys return 401 key_inactive immediately. There is no grace period — plan rotations to avoid downtime.

Rotation procedure. To rotate a key without downtime:

1. Generate a new key with the same scopes.
2. Update your integration to use the new token (deploy, redeploy, etc.).
3. Confirm the new key is in use (the admin console shows last-used timestamps).
4. Revoke the old key.

The platform does not detect compromise on its own — if you suspect a key has leaked, revoke it manually and audit the call log for unexpected activity.

Authentication failures (401)

The API returns 401 Unauthorized with one of two detail codes:

{ "detail": "invalid_key" }

The header is missing, malformed, the prefix doesn’t exist, or the secret doesn’t match the stored hash.

{ "detail": "key_inactive" }

The key was found but has been revoked or has passed its expiry.

In both cases, do not retry — the request will keep failing until the key situation changes.

Authorization failures (403)

If the key is valid but doesn’t carry the scope the endpoint requires, the API returns 403 Forbidden:

{ "detail": "You do not have permission to perform this action." }

The fix is operator-side: ask whoever manages the key to add the missing scope (or issue a new key with the right scopes). Retrying with the same key won’t help.

Security notes

• Treat the raw token like a password. Anyone holding it can read or modify the tenant’s data within the granted scopes.
• Never commit it. Use a secret manager, environment variables, or your platform’s secret store.
• Never log it. Strip Authorization headers from request logs in your own systems.
• The platform does not display the raw token after creation. If you forgot to save it, you cannot recover it — generate a new one.
• Use TLS for every request. All endpoints require HTTPS; HTTP requests are rejected.