Operations

Security checklist

Ten rules for using API keys safely, and what Quilo does on its side.

Your side#

One key per integration, named after it (Website form, POS Zurich).
Least access: Read only unless the integration must write.
Set an expiry and rotate before it runs out (see Authentication).
Server side only: never in a web page, app, browser extension or public repository.
Secrets storage: environment variables or a secret manager; never in code, chat, email or tickets.
Secret scanning: add the pattern qk_[0-9a-f]{10}_[A-Za-z0-9_-]{32} to your scanner.
Create keys with the right person: a key acts as its creator. For company-wide integrations, an owner or admin may create the key with an account meant for integrations, so it does not stop working when an employee leaves.
Check usage: look at Last used and Recent requests now and then; revoke keys that are no longer used.
Validate what you send: data from forms goes into your CRM; filter spam and limit lengths before sending.
Log request IDs, not keys: errors contain request_id; that is all support needs.

Keys are random (192 bits of secret), shown once, and stored only as SHA-256 fingerprints.
Every request runs with the key owner's database permissions (row-level security); a read key is refused by the database on every write.
Every query is limited to the key's company; IDs from other companies are answered like IDs that do not exist.
Unknown fields and filters are refused; input is length- and type-checked; text is never rendered as HTML.
Keys stop when revoked, expired, when the person leaves, when the company switches API access off, or when the account is suspended.
Per-key rate limits; request logs without bodies, kept 90 days; key creation and revocation in the security log.
No browser access (no CORS), HTTPS only, Cache-Control: no-store on every answer.

Write to support@teknocare.ch with the subject "Security". Please do not test against other customers' data.