API security

If you use the STYD API, your API keys are sensitive credentials. Handling them carefully is an important part of security.

Keys belong to a workspace

API keys are created per workspace, by an owner or admin, and let external tools call the STYD API on that workspace's behalf. The key is sent in the x-api-key request header. A workspace can hold up to 5 active keys.

What a key can do

A key acts as a member of its workspace, with the member role. It is never an owner or an admin.

It can call the public API only. On any other address it is refused.

It follows the table visibility set for its own member.

STYD stores only a hash of the key, so a lost key cannot be shown again.

Owners and admins can read the conversations a key started, read-only.

Treat keys like passwords

A new key is shown in full only once, when you create it. Copy it then and store it securely. Never share keys, never commit them to source control, and never expose them in client-side code.

Rotate and revoke

Give each key a clear label so you know where it is used.

Revoke keys you no longer need. Revoked keys stop working immediately.

If a key may have been exposed, revoke it and create a new one.

How to authenticate and call specific endpoints is covered in the API section. This page is about keeping keys safe.

Limits that protect the service

Questions through the API and AI apps are limited in number per minute and in length, and a person or key whose questions keep failing is paused for the rest of the hour. The forms on the public site have a submission limit, and invitation emails are limited per workspace, per person and per address. If STYD's total AI use over a day becomes unusually high, new questions can be paused for a while, free ones first, with the message “STYD is busy right now”. Nothing is charged for a paused question. The request limits are listed in Billing & Limits.