API key security

Your API key identifies your organization. It’s public by design — safe to embed in a frontend bundle, the same trust level as the organizationId qrati-connect-ts already sends from the browser. It is not a secret like a Stripe API key, and the SDK doesn’t ask you to keep it server-side.

What actually protects you

The real security boundary is your organization’s domain allowlist — the same one that already restricts where qrati-connect-ts can be embedded. A request authenticated with your key is only accepted if it comes from an origin on that allowlist. An attacker who copies your key out of your JS bundle still can’t call the API from their own site.

Ask a Qrati admin to add every origin your SDK integration runs from (including localhost during development, if needed) to your organization’s allowed origins.

This only applies to calls made from a browser — a browser always sends an Origin header, so there’s always something to check. A server-to-server call (Node backend, no browser involved) has no Origin header at all, so the allowlist doesn’t apply to it; the key itself, kept like any other backend credential, is what scopes that traffic to your org. See Browser & server.

What the key does not do

• It does not identify an individual end-user — see Identity model for that.
• It is not scoped per-domain itself; the domain check is separate and server-side.
• There’s currently no self-serve rotation/revocation UI. If a key needs to be rotated, ask a Qrati admin.