Authentication
Every endpoint requires your integration's API key. There is no login or token exchange — the key is the credential.
Use x-api-key
curl "$ALRIK_API_BASE/v1/integration" \
-H "x-api-key: $ALRIK_API_KEY"
This is the scheme to use for server-to-server integrations.
The same key is also accepted as a bearer token:
curl "$ALRIK_API_BASE/v1/integration" \
-H "Authorization: Bearer $ALRIK_API_KEY"
Use this where a tool only offers a bearer-token field — an identity provider configuring SCIM, for example. Send one header, not both.
Environments
Staging and production are fully separated, each with its own key.
| Environment | Base URL |
|---|---|
| Staging | https://api-staging.alrik.com |
| Production | Provided by Alrik during onboarding |
A separate key for reporting
The billable-tours and engagement endpoints normally use their own API key,
so reporting access can be granted without also opening up the order-creation
endpoints. Ask tech@alrik.com if you need one.
What your key identifies
An API key maps to exactly one integration, which carries:
- a set of permission flags — see Permissions
- a list of locations it may act on — see Locations
- optionally a company, which some endpoints require
Call GET /v1/integration to see all three.
Failure responses
| Situation | Status | Body |
|---|---|---|
| Neither header sent | 403 | Auth header is missing |
Authorization sent without a usable key | 403 | Bearer token invalid |
| Key is not recognised | 401 | Invalid API key |
| Key is valid but lacks the permission | 403 | Permission '...' is required but not granted for this integration |
| Location does not belong to the integration | 403 | Invalid location id |
Keeping the key safe
The key grants everything its integration is permitted to do. Treat it as a server-side secret: never ship it in browser or mobile code, and pass it through your own backend instead.