API Keys

Settings → API Keys creates keys that let a script, a scheduled job or another system call the CRMSix REST API. Each key acts as a run-as user you choose, so it can do exactly what that user can do, and nothing more.

When to use an API key

You want to Use
Call the API from your own script, a scheduled job or a low-code toolAPI key (this page)
Connect a server-to-server integration that expects OAuth 2.0Connected App
Let people use CRMSix from Claude or another AI appMCP Server

Create a key

  1. Go to Settings → API Keys and choose New API Key.
  2. Give it a name that says what uses it, for example “Nightly ERP sync”.
  3. Choose the run-as user. The key acts as this user: their profile, permissions and sharing decide what it can see and change.
  4. Choose when it expires: never, or after 30 days, 90 days, 180 days or 1 year.
  5. Tick Read-only if the integration only needs to read.
  6. Create the key and copy it straight away. It’s shown only once; CRMSix keeps just its start (scl_…) so you can recognise it later.

Only admins can manage keys, and only while signed in to CRMSix: a key can’t be used to create or revoke other keys. An organization can have up to 50 active keys.

Use the key

Send it with every request, in either of these headers:

Authorization: Bearer scl_…
X-API-Key: scl_…

For example, to list cases:

curl https://<your CRMSix address>/api/cases \
  -H "X-API-Key: $CRMSIX_API_KEY"

The full list of endpoints, fields and examples is in the API reference at /apidoc on your CRMSix site. Records can also be queried with COQL through POST /api/query.

What a key can do

  • Same access as its userThe run-as user’s object permissions, field security and sharing apply to every call.
  • Read-only keysCan only read (GET requests). Anything that would change data is refused.
  • Traceable changesRecords show the run-as user as Created By and Updated By; field history shows the source as API key: name.
  • Same rules as peopleValidation rules, workflow rules and flows run as they do when someone saves a record by hand.

Manage keys

  • The list shows each key’s name (with a Read-only badge), its start, run-as user, status, when it was last used, when it expires, and who created it.
  • If the run-as user is deactivated, the key stops working; the list warns you.
  • Revoke stops a key at once and can’t be undone. Anything still using it gets an authentication error.
  • To change a key’s user, access or expiry, create a new key, switch the integration over, then revoke the old one.

Keep keys safe

A key is a password. Anyone who has it can act as its run-as user. Keep it in a secrets store or environment variable, never in source code, a spreadsheet or a chat message.
  • Make a dedicated integration user with a profile that has only the access the integration needs, and use it as the run-as user.
  • Use read-only keys wherever writing isn’t needed, and set an expiry.
  • Use one key per integration, so you can revoke one without breaking the others.
  • If a key may have leaked, revoke it straight away and create a new one.

Troubleshooting

401 Unauthorized
The key is wrong, revoked or expired, its run-as user is inactive, or the header is missing. Check that the whole key was copied.
403 Forbidden
The key works, but its run-as user isn’t allowed to do this, or the key is read-only and the request would change data.
A record or field is missing from the response
Sharing or field security hides it from the run-as user. Check what that user sees when signed in.