Authentication

Bearer tokens on the Authorization header.

All /v1/pulse/* JSON endpoints require an API key. Two categories are public: /v1/health and /v1/status (so uptime monitors can run without one), and the composite HTML widget /v1/pulse — the whole point of an embed is anonymous use on a customer’s site.

Sending the key

Attach your key to every request as a Bearer token:

Authorization: Bearer ch_live_a4c9e2f8...

Example:

curl "https://api.trychora.com/v1/pulse/weather?lat=51.38&lng=-2.36&start=2026-10-14&end=2026-10-18" \
-H "Authorization: Bearer $CHORA_API_KEY"

Errors

Missing key:

{
"error": {
"type": "authentication_error",
"code": "missing_api_key",
"message": "Provide `Authorization: Bearer <api-key>`.",
"request_id": "req_..."
}
}

Invalid key:

{
"error": {
"type": "authentication_error",
"code": "invalid_api_key",
"message": "The provided API key is not recognised.",
"request_id": "req_..."
}
}

Both return HTTP 401.

Never expose keys client-side

Chora keys grant access to your rate-limit quota. Treat them like any other server credential. Never ship one in a browser bundle or mobile app. If a key leaks, contact us and we’ll revoke and reissue.

For public-facing embeds on customer booking pages, use the widget endpoints — they render server-side and don’t require a key.