Authentication

Send your Credential's API key value in the X-API-Key header when making authenticated requests from your server. The API Reference shows which operations require this header.

Send the key

X-API-Key: your_service_account_credential

Security boundary

Credentials belong in server-side secret storage. Do not place them in query strings, fragments, browser bundles, analytics properties, logs, or screenshots. Use separate Service Accounts for applications or environments that need independent permissions, attribution, or rate budgets.

Create a Service Account inside your Project in the Dashboard, then issue a Credential. Its secret is shown only once: store it before leaving the reveal screen. The API identifies the Project and Service Account from that Credential; you do not add ownership labels to your request.

Separate workload identities

Give each independently operated application or environment its own Service Account. Its one or two Credentials authenticate the same durable workload identity and share its permissions and rate budget. Use a second Credential only for bounded rotation overlap, not to create another workload or another rate budget.

Rotate deliberately

Store the replacement key before changing application configuration, verify a bounded test request, and then revoke the old key through the Dashboard. Avoid copying credentials through URLs or client-side state during rotation.

Handle rejected authentication

Treat an authentication rejection as a configuration or credential lifecycle problem. Do not retry the same rejected credential in a tight loop. Confirm the header name, secret source, and active key state, then use the documented error and X-Request-ID for investigation.

Continue with Service Accounts, Credentials, Projects, Errors, and Retries & timeouts.