API security best practices

A checklist for running integrations safely, from scoping and storing keys to rotating them, reacting to a leak and rendering SOP HTML.

Business plan Updated Sep 19, 2026

On this page

An API key can read everything its workspace can see, and a read and write key can create SOPs and assign them. Treat keys like passwords.

How SOPCompass protects keys

A key is shown once, when it’s created. SOPCompass stores only a SHA-256 hash of it, so nobody, including SOPCompass staff, can read your key back.
Keys are refused if they appear in a URL, so they don’t end up in logs.
Every request is scoped to the key’s workspace. Anything in another workspace answers 404, so a key can’t even learn it exists.
A key stops working the moment it’s revoked, and when the admin who created it is removed or demoted.

Use read only keys unless the integration must create SOPs or assign them.
One key per integration, named after it. You can revoke one without breaking the others, the key list shows when each was last used, and each gets its own rate limit.
Create integration keys from an admin account that will stay an admin, such as the workspace owner’s. A key stops working with 401 creator_not_admin when its creator is removed from the workspace or is no longer an owner or admin, and assignments made with it are recorded under that person’s name.

Keep keys server-side: in a secret manager, environment variables, or your automation tool’s credential store (an n8n credential, a Zapier or Make connection field).
Never ship a key to a browser, mobile app or browser extension. Anyone can read it from there. Put a small server or serverless function in between.
Never commit keys to source control. Add secret scanning for the sc_live_ prefix to your repositories and CI.
Never put keys in URLs or query strings. The API refuses them with 401 key_in_url.
Don’t log the Authorization header. Redact it in your HTTP client’s debug logging and in error reports.

Rotate by creating a new key, switching the integration over, then revoking the old key. See Rotate a key.
Revoke immediately if a key may have been exposed: pasted in chat, committed, logged, or known to someone who has left. Revoking takes effect on the next request.
Review the key list from time to time. Revoke keys that show Never used or haven’t been used in months.
Monitor for 401 and 403 in your integrations. They mean a key was revoked, its creator lost admin rights, or the plan changed, and a person needs to act.

Sanitize SOP HTML before rendering it. body_html and step html are returned as stored. Run them through an HTML sanitizer (DOMPurify, nh3, bleach) before putting them in your own pages.
Respect who may see what. A key sees every library in the workspace. If you publish SOPs somewhere others can read, such as an intranet or a chatbot, filter by library_id or departments so you don’t expose SOPs meant for a smaller group.
Emails are personal data. GET /people and assignments include members’ sign-in emails. Store only what you need.

POST /assignments is safe to retry: a duplicate answers 422 already_assigned.
POST /sops isn’t: a retry after a lost response can create a second SOP. Check first.
New SOPs are visible right away to everyone who can see the library, even though the API returns them with "published": false. See how the new SOP appears in the app.