Security & IP allow lists.

Defense in depth

Every CHeKT App has four layers of protection. Each one stands alone — if any single layer fails, the others contain the damage. We strongly recommend turning all four on for any app touching production.

IP allow lists

The IP allow list is the single most impactful security control after permissions. It moves the attack surface from "anyone with the key" to "anyone with the key and network access to your infrastructure".

Configuring the list

Open your app in the dealer portal at Settings → CHeKT Apps → [your app] → Security and add one IP or CIDR per line. Both IPv4 and IPv6 are supported. Save and changes take effect within 30 seconds.

# Allow a single IP
203.0.113.42

# Allow a range
198.51.100.0/24

# Allow IPv6
2001:db8::/32

# Comma-separated, one per line, or both
203.0.113.42, 198.51.100.0/24
2001:db8::/32

When to use it

Production servers

Always. Lock to your VPC NAT egress IPs or your hosting provider's outbound range.

CI / CD pipelines

If your pipeline calls the API, add the runner pool IPs. GitHub Actions, GitLab Runners, and CircleCI publish their ranges.

Local development

Skip the allow list on dev apps — use a separate CHeKT App with limited scopes instead. Office IPs change.

Distributed scrapers

Not a good fit. If you genuinely call from many short-lived workers, rely on permissions + rotation instead.

Key rotation

Rotate API keys quarterly, immediately after any team member with access leaves, and any time you suspect compromise. Rotation is a one-click operation in the dealer portal.

1. Open the app's Security tab. Click Rotate key. CHeKT generates a new key and shows it once.
2. Copy the new key into your secret manager. The old key is still valid for 24 hours.
3. Deploy the new key to all environments. Confirm everything is calling with the new key by watching the request log.
4. Revoke the old key. Click Revoke previous in the dealer portal to end the grace period early.

Webhook signing

The webhook signing secret is separate from your API key. Each app has one signing secret used to sign every outgoing webhook. If an attacker somehow learns your webhook URL, they still can't forge a payload without the signing secret.

# Every CHeKT webhook carries these
X-CHeKT-Signature: 4d2c9b...
X-CHeKT-Timestamp: 1748259694
X-CHeKT-Event-Id: evt_2hKqx9
X-CHeKT-Delivery-Id: del_8jx2k
X-CHeKT-Attempt: 1

See the webhook verification section for the full HMAC-SHA256 verification snippet including replay protection.

Audit log

Every API call and webhook delivery for every app is logged with timestamp, request ID, scope used, and result. The log is available in the dealer portal and via the operators:read API scope.

When something looks off

Filter the log by app name and time window. Look for unfamiliar request IDs, unexpected scopes, or unusual call patterns.

Compliance reviews

Export the last 90 days as CSV or JSON. The log is retained for 365 days; enterprise plans extend to 7 years.

Incident response

Pull every action taken in the suspected window. Cross-reference with your own application logs using the request_id field.

If something goes wrong

You suspect a key is compromised, an app behaves unexpectedly, or you see calls you didn't make. Move quickly through this checklist:

1. Rotate and revoke immediately. Don't wait the 24-hour grace period. Use the dealer portal.
2. Tighten the IP allow list. If you weren't using one, add your egress IPs now.
3. Pull the audit log. Look for the request IDs of suspicious calls. Save them.
4. Email security@chekt.com with the request IDs. We can correlate with edge logs and confirm scope of access.
5. Notify your dealer admin and impacted sites, if any state was changed.

Next steps

• Permissions referenceThe first layer of defense.
• Webhook signingVerify every incoming event.
• Platform securityHow CHeKT secures the platform itself.