Skip to main content

Overview

shipd has three kinds of credentials. SDK keys read flags from the edge (data plane). Management API keys and service account tokens change flags through the control plane. A credential for one plane never works on the other.

At a glance

SDK keys are created for the environment that is active in the dashboard when you click Create SDK key. Every key is shown once; copy it before you close the dialog.

Server SDK key vs client SDK key

Use a server SDK key when the code runs on infrastructure you control. Use a client SDK key when the code ships to a user’s device. Because client keys currently receive the full snapshot, anyone with the client key can read your targeting rules and flag values. Do not put secrets in flag values or rule conditions.

Which credential should I use?

The CLI reads SHIPD_API_KEY for both management API keys and service account tokens. See Sync flags in CI and Create a service account.

Rotate or revoke a credential

Revocation fails closed on the edge as soon as it propagates; open WebSocket connections are revalidated at least every 60 seconds. See Edge API. A management API key is checked against its creator’s current role and project access on every use. If the creator loses access, the key stops working.

Common mistakes

Any key in client code is public. If you put a shipd_sdk_server_ key in a browser bundle (for example, in a NEXT_PUBLIC_ environment variable), revoke it and create a client key for the browser. Keep the server key in a server-only secret.
createClient({ sdkKey: "shipd_mgmt_…" }) fails: the edge returns 401 for any credential that is not an SDK key. Create an SDK key on the project’s SDK keys page.
SHIPD_API_KEY=shipd_sdk_… fails with 401 unauthenticated: SDK keys only work on the edge. Run shipd login locally, or use a service account token in CI.
Each SDK key reads exactly one environment. If flags show staging values in production, check that the key was created with the production environment active.