BuildGet an API key

Get an API key

Every call to the Syntic API carries a key that identifies your organization. The key decides which plan the request counts against and which wallet pays for it, so treat it like a password.

Key types

The Console issues two kinds of key. Only one of them works with the API.

PrefixKindUse it for
sk_live_PrivateServer-side calls to the Syntic API. This is the one you want.
pk_live_PublicClient-side widgets in a browser. The API refuses it with 403 public_key_rejected.

You may also come across keys that start with sk_syntic_. Those are created for Syntic Code and are accepted on the same header.

Create a private key

  1. Sign in to the Syntic Console and pick the organization the usage should be billed to.
  2. Open Settings → API Keys.
  3. Under Private API Keys, create a key and give it a name you will recognise later, such as the service or environment it belongs to.
  4. Copy the full key and store it somewhere safe, for example a secrets manager or an environment variable on your server.
⚠️

The full key is displayed once, right after you create it. Syntic stores only a fingerprint of it, so a lost key cannot be shown again. Revoke it and issue a replacement instead.

If your account or organization uses multi-factor authentication, the Console asks you to confirm a second factor before it creates the key.

Restrict a key to certain websites

While creating a key, you may list the web origins allowed to use it, such as https://shop.example.com. Once the list has at least one entry, the API only accepts the key from a request whose Origin (or, failing that, Referer) header matches. A request that sends no origin at all is refused with 403 origin_not_allowed.

How entries are matched:

  • Only the scheme, host and port count. A pasted address with a path, such as https://shop.example.com/checkout, is reduced to https://shop.example.com.
  • An entry without a scheme, such as shop.example.com, is treated as https://.
  • The default ports (443 for https, 80 for http) are ignored, so https://shop.example.com:443 and https://shop.example.com are the same origin.
  • A leading *. allows any subdomain: https://*.example.com matches https://eu.example.com and https://a.b.example.com, but not https://example.com itself. Add the bare domain as its own entry if you need it.
  • An entry that cannot be understood is skipped, but the key still counts as restricted. If no entry can be understood, every request is refused.

Server-side code usually sends no Origin header, so leave the list empty for keys used from your backend.

⚠️

An origin list limits where a key is accepted from, but it does not hide the key. Anyone who can read a page’s source can copy a key embedded in it and call the API from a server, where they can set any headers they like. Keep private keys on your server.

Who can see which keys

  • Owners and administrators see and can revoke every key in the organization.
  • Developers see and manage only the keys they created themselves.

The Console lists each key with its name, the first few characters, when it was created and when it was last used. Creating and revoking keys are recorded in the organization’s audit log.

Use the key

Send the key in the Authorization header of every request:

Authorization: Bearer sk_live_...

Keep it in an environment variable or your platform’s secret store and read it at runtime:

export SYNTIC_API_KEY="sk_live_..."

To check that a new key works, send a one-line request and look for a 200 status:

curl -s -o /dev/null -w "%{http_code}\n" https://app.syntic.ai/v1/chat/completions \
  -H "Authorization: Bearer $SYNTIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"stream": false, "max_tokens": 5, "messages": [{"role": "user", "content": "ping"}]}'

This sends a real request, so it uses a few tokens of your allowance.

Which organization pays

Each key is tied to the organization that was selected when you made it. Every request made with it counts against that organization’s plan allowance and, once the allowance is used up, its usage credits. To bill a different organization, switch to it in the Console and create a key there.

The person who created a key must stay an active member of its organization. If they leave or are removed, their keys stop working with 403 org_membership_required. Create keys for long-running services with an account that will stay in the organization.

Key lifetime

A key made in the Console has no end date: it keeps working until someone revokes it. A key that has an expiry date and has passed it is refused with 401 expired_api_key.

Revoke a key

Revoke a key from the same API Keys page. It stops working immediately: requests that use it receive 401 revoked_api_key. Revoking cannot be undone, so create the replacement first if a service depends on the key.

Keep keys safe

  • Never put a private key in browser code, a mobile app or a public repository.
  • Use one key per service or environment; revoking one then leaves the others working.
  • Rotate keys when someone with access leaves the team.
Was this page helpful?