Authentication

Everything you need to know about API keys, scopes, access modes, and keeping your AI systems securely connected to Squillify.

Two authentication surfaces

We keep human (dashboard) access and machine (runtime) access cleanly separated, so each one only ever does what it should:

Surface	Auth method	Purpose
Dashboard	Clerk JWT (Bearer token)	Managing keys, MicroSkills, and viewing usage
Runtime API	Squillify API key (X-API-Key header or Authorization: Bearer sq_live_*)	Executing MicroSkills, MCP connections

Dashboard JWTs can’t invoke MicroSkills, and API keys can’t reach dashboard endpoints. That separation is deliberate — it means your agents never end up holding admin privileges.

API keys

API keys are how you authenticate MicroSkill execution. Every key starts with the sq_live_ prefix, and you can pass it whichever way suits your client:

X-API-Key header — X-API-Key: sq_live_abc123...
Authorization header — Authorization: Bearer sq_live_abc123...

Both are equivalent — use whichever your client or framework makes easiest.

Example request

cURLbash

curl -X POST https://api.squillify.com/v1/execute \
  -H "X-API-Key: sq_live_abc123..." \
  -H "Content-Type: application/json" \
  -d '{ "skillKey": "text.slugify", "input": { "text": "Hello" } }'

Warning

You’ll see the full API key just once — right when you create it. Tuck it away somewhere safe (an environment variable or secret manager is ideal), and please never commit keys to source control or ship them in client-side code.

Scopes

Every valid API key automatically comes with two scopes:

Scope	Grants
skills:read	List available tools and catalog metadata
skills:invoke	Execute MicroSkills via REST or MCP

These scopes are fixed for every valid API key and enforced on our side. If a request arrives with an invalid or revoked key, it gets a 401 Unauthorized in return.

Access modes

Every API key has an access mode that decides which MicroSkills it can discover and invoke. Here are your three options:

ALL_ENABLED_SKILLS

The key can invoke any MicroSkill enabled in your tenant. As new MicroSkills get added to the catalog and enabled, they become available automatically — nothing for you to wire up.

SELECTED_SKILLS

The key can only invoke the exact MicroSkills you assign. This is the one to reach for with production agents, so each key operates with least privilege — just the MicroSkills it actually needs.

NONE

The key has no MicroSkill access at all. Handy for keys you’ve created but haven’t configured yet, or as a quick temporary lockout without fully revoking.

Tip

A good rhythm: start with ALL_ENABLED_SKILLSwhile you’re developing and testing, then switch production keys to SELECTED_SKILLS to keep things least-privilege.

Key lifecycle

You can manage a key through its whole lifecycle right from the dashboard:

Action	Effect
Create	Generate a new key. The secret is displayed once.
Rotate	Create a new key linked to the previous one. The old key is revoked immediately. MicroSkill grants are copied to the new key.
Revoke	Permanently disable the key. It cannot be re-enabled.
Delete	Remove the key entirely. Associated usage data is preserved.

Security best practices

A few habits that’ll keep your keys safe:

Store keys in environment variables or a secret manager — never hardcode them.
Create a separate key for each agent, environment, or project, so you can rotate and revoke them independently.
Use SELECTED_SKILLS mode in production to limit each key to exactly the MicroSkills it needs.
Keep an eye on your Usage dashboard for unexpected invocation patterns — they can be the first sign of a compromised key.
Rotate keys from time to time, especially when teammates move on or environments are retired.