Authorization header. Tikk supports two credential types. API keys for your own scripts and server-to-server integrations. OAuth access tokens for partner apps acting on behalf of another user. Both use the same bearer token format, so the request structure is the same.
Sending credentials
Include your credential in theAuthorization header of every request:
API keys
API keys are the simplest credential type. They are tied to your own Tikk account, never expire on their own, and automatically carry all available scopes. Use them for scripts, automation, and any server-side integration where you are accessing your own data.1
Open API Keys settings
Go to Settings → API Keys in your Tikk account dashboard.
2
Create a new key
Click Create new key and give it a descriptive name so you can identify it later (for example,
zapier-integration or analytics-script).3
Copy the key immediately
Copy the key. It starts with
tikk_sk_ and is shown only once. Tikk does not store the raw value, so you can’t retrieve it after closing the dialog.4
Store the key securely
Save the key in your environment variables or a secrets manager (such as AWS Secrets Manager, HashiCorp Vault, or a
.env file that is excluded from version control).OAuth 2.0 (for partner apps)
If you are building an integration that accesses Tikk data on behalf of another user, use the OAuth 2.0 authorization code flow. Your users grant your app permission through Tikk’s hosted consent screen, and Tikk returns an access token your app can use on their behalf.
Start the flow by redirecting the user to the authorization URL with your app’s parameters:
redirect_uri with a code parameter. Exchange that code for an access token at the token URL, then store the access token and refresh token securely. Use the refresh token to obtain a new access token before the current one expires.
Credential scope and user isolation
A credential (API key or OAuth token) can only access data owned by the user it belongs to. You can’t use your own API key to read another user’s profile, availability or bookings. Requests for resources outside your account return404, not 403, so the existence of other users’ data is never revealed.
See the Scopes page for the full list of available scopes, which endpoints require them, and what happens when a required scope is missing.