Private and public keys
Syntic issues two types of API key. Private keys start with sk_live_ and are for your servers; they are the keys that call Syntic models. Public keys start with pk_live_ and are meant for client-side SDK use in a browser; the models API refuses them.
Side by side
| Private | Public | |
|---|---|---|
| Starts with | sk_live_ | pk_live_ |
| Label in the Console | Private — server-side | Public — client-side SDK |
| Calls the chat completions API | Yes | No: refused with 403 public_key_rejected |
| Where it should live | Your server, secret store or environment | Web pages that use a Syntic client SDK |
| Allowed origins | Optional (offered in the main app) | Offered in the Console and the main app |
Which one do I need?
Almost always a private key. If you’re following the developer docs, a tutorial, or connecting a tool that asks for a “Syntic API key”, create a private key.
Only create a public key if Syntic’s documentation for a specific client-side SDK tells you to. Pair it with an allowed-origins list so only your site can use it. See Restrict a key to allowed origins.
Other credentials you might see
- Keys starting with
sk_syntic_belong to Syntic Code. They are accepted by the API in the sameAuthorizationheader. - When you sign in to Syntic Code with your browser, it uses a sign-in token instead of a key. You don’t need to manage it in the Console.
See Use the API with Syntic Code.
Both types are treated as secrets
Even public keys are tied to your organization and its billing. Keep both types out of public repositories, and revoke any key you no longer use.