Every /v1 endpoint requires an API key. Send the key as a bearer credential in the Authorization header. The public /health and /openapi.json endpoints do not require authentication.
Send the bearer header
Authorization: Bearer YOUR_API_KEY
The key identifies its organization and allowed scopes. There is no organization-switching parameter. If you run a service for several organizations, keep each customer's credential and data partition separate. Choose the correct credential before making a request, not after receiving the response.
Store secrets on the server
Use your deployment's secret manager or protected environment configuration. A browser can inspect JavaScript, source maps and network requests, so a hidden input or frontend environment variable is not secret storage. Route authenticated calls through your own server.
Do not paste keys into support tickets, analytics properties, error screenshots or shared request collections. Redact the Authorization header in HTTP logs. Use a recognizable key name in the app so an operator can identify and revoke the right integration without seeing its secret.
Understand failed authentication
A missing, revoked or invalid key returns 401. A valid key without the required permission returns 403. Retrying either response unchanged will not solve the problem. Verify configuration for a 401 and compare the endpoint's scope requirements for a 403.
An authenticated request can still return 404 when the resource does not belong to the key's organization. Check where the resource was created before treating the ID as incorrect. The API key scopes guide lists the permission boundaries.
Separate credentials by purpose
Give reporting a read-only key and invitation sending its own key. This makes a lost credential easier to contain and keeps a reporting bug from becoming a write operation. Revoke unused keys promptly. When replacing a working credential, follow the rotation procedure and verify the new key before removing the old one.
For a first connection, the quickstart uses a read-only template request. It is a useful deployment check because it verifies both authentication and an actual permission without changing participant records.