Server side only
Never embed company API keys in browser JavaScript, public pages, URLs, source control, logs, screenshots, or mobile binaries. Store them in a managed server-side secret store and send only over HTTPS.
Developer & API documentation
Treat each company key and webhook secret as a production credential. Tenant enforcement is server-side, but integrators remain responsible for secret storage, receiver security and data minimization.
Never embed company API keys in browser JavaScript, public pages, URLs, source control, logs, screenshots, or mobile binaries. Store them in a managed server-side secret store and send only over HTTPS.
Create a separate named key per integration/environment, limit administrative ownership, review last use, and revoke unused keys. Because keys have company-wide API capability rather than granular scopes, do not share one key across systems.
Create and deploy a replacement, revoke the exposed key, inspect audit and usage records, and investigate downstream data access. A revoked key cannot be restored.
Require HTTPS, retain the signing secret outside code, validate HMAC over the raw body before JSON parsing, compare in constant time, validate the event header and schema, constrain body size, and process personal data under your retention and access policy. Rotate the webhook secret from the admin configuration when exposure is suspected.
Do not trust caller-supplied tenant IDs to authorize access. The documented key routes derive tenant scope from the key, and lifecycle/plan authorization is enforced server-side. CardIQ does not claim IP allowlisting, mTLS, configurable API scopes, a public SLA, or a published rate limit for these routes. Confirm additional controls through an approved enterprise scope.
Explore the CardIQ platform or review the workflow from verification through identity deactivation.
See how CardIQ works View pricing