Skip to Content
Accounts, plans and API keysAPI keys

Manage workspace API keys

This page gets you a working SynapseX Platform API key and a safe way to live with it. By the end you will have created an sk-synapsex-… key, proved it works with a single command, and know how to rotate it later without taking your application down.

These keys belong to a workspace, not to you personally — see Workspaces and teammates. They are also not the sxc_… keys used by SynapseX Desktop and the CLI; see API keys and scopes.

How do I create an API key?

  1. Sign in at platform.synapsex.ai .
  2. Go to /dashboard/api-keys.
  3. Give the key a name and create it.
  4. Copy the sk-synapsex-… value immediately.

The plaintext key is returned exactly once, at creation. Only a SHA-256 hash is stored, so it can never be shown again. If you lose it, delete the key and create a replacement.

What can I set on a key?

At creation you set the name, and optionally a spend limit for that key. Both can be changed later; the secret itself cannot.

The key list shows, for every key: its id, its name, when it was created, when it was last used, its scopes, and its configured limits. It never shows the secret.

Scopes

Every key is created with the scope chat:write, and that is the scope the API actually enforces. A key without it is refused with HTTP 403 and the message API key does not have chat:write scope when it tries to call chat completions.

How do I revoke or rotate a key?

Revoking is deleting the key from /dashboard/api-keys. The credential stops working immediately, on the next request.

Rotating without downtime is three steps in this order:

  1. Create the replacement key and copy its value.
  2. Deploy the new value everywhere the old one is used, and confirm traffic is flowing.
  3. Delete the old key.

Doing it in that order means there is never a moment where your application has no valid credential. Deleting first and creating second guarantees an outage.

Service accounts

For unattended automation — a CI job, a cron worker, a backend service — create a service account at /dashboard/settings/service-accounts instead of a key that looks like it belongs to a person. A service account is a named machine identity in the workspace, and its API key is returned once at creation just like any other key.

It behaves the same way at request time: same chat:write behaviour, same workspace credits, same usage reporting. The value is organisational — the key is attached to a named system rather than to an individual, so it survives that person leaving and it is obvious what breaks if you revoke it.

How should I store the key?

  • Put it in an environment variable. The official SDKs and examples read SYNAPSEX_API_KEY:

    export SYNAPSEX_API_KEY=sk-synapsex-YOUR-API-KEY

  • Never commit a key to source control, including private repositories, and never paste one into an issue, a log or a screenshot.

  • Use a separate key per environment and per application. Then a leak in staging is fixed by revoking one key, with no effect on production.

Check that a new key works

The fastest proof is listing the models, which needs nothing but a valid key:

curl -s https://platform.synapsex.ai/api/v1/models \
  -H "Authorization: Bearer $SYNAPSEX_API_KEY"

A working key returns an OpenAI-shaped list — {"object":"list","data":[…]} — where each entry has an id, "object": "model", "owned_by": "synapsex" and a context_window.

Two failures worth recognising immediately:

ResponseWhat it means
401 with {"error":{"message":"Invalid or expired API key","type":"authentication_error"}}The key is wrong, was deleted, or the header is malformed.
402 with {"error":{"message":"Insufficient credits","type":"insufficient_quota"}}The key is valid but the workspace balance is at or below zero. Add credits.

A 402 here is good news about your key: authentication succeeded. See API credits, spend limits and alerts.

WorkspacesCredits and spending