How Iteradian handles your keys, your tenancy and your data.
Iteradian secures RPC access with HMAC-SHA256 hashed API keys, per-key IP allowlists enforced by the gateway on every request, and TOTP two-factor authentication on password sign-in. Every organization-scoped API route checks membership before its handler runs. Access tokens are held in memory only and the refresh token is an httpOnly, SameSite cookie, so no token is ever written to localStorage.
Verified against the gateway request path on 2026-09-24.
One organization cannot read another
Every API route that carries an organization id runs a membership guard before the handler. The caller is authenticated first, then checked against the organization named in the URL — reading an id from the path is never enough to reach the data behind it. The guard list is asserted by a test, so a new organization-scoped controller cannot ship without it.
API keys are hashed at rest
Keys are hashed with HMAC-SHA256 and the plaintext value is displayed exactly once — at creation, or at rotation for the replacement key. Iteradian cannot recover a lost key — it can only be rotated, which revokes the old key immediately. Keys can be created, rotated and revoked, and every action is recorded in the audit log.
Per-key IP allowlists, enforced at the gateway
A key restricted to a set of source addresses is checked against the request on every call, before it reaches a node. The address is taken from Cloudflare’s CF-Connecting-IP when the request provably came through Cloudflare, and otherwise from the trusted-proxy hop count — not from a caller-supplied X-Forwarded-For header, which anyone could set.
No tokens in localStorage
Access tokens are held in memory for the lifetime of the tab. The refresh token is issued as an httpOnly, SameSite cookie and is rotated on use, so a cross-site scripting bug cannot exfiltrate a long-lived credential from browser storage. Alert-channel secrets and node access tokens are encrypted at rest.
Two-factor authentication
Accounts support TOTP two-factor authentication with QR setup and single-use backup codes; it applies to email-and-password sign-in. Sign-in options include email and password with bcrypt hashing, Google SSO, GitHub SSO and passwordless magic links, alongside email verification and password reset.
Granular organization roles
Organizations support owner, admin, developer, viewer roles backed by a 28-permission catalog, so a teammate who only needs to read analytics never needs the ability to rotate a production key. Add teammates by email — they need an Iteradian account first, and they join the organization straight away.
Full audit log
Every platform action is recorded with the actor, source IP, action, target and metadata. Keys carry an itrd_live_ or itrd_test_ prefix so production and test keys are easy to tell apart; the environment is a label, and all of an organization’s keys share its plan limits.
What this page does not claim
- No certifications. Iteradian holds no SOC 2, ISO 27001 or PCI DSS certification or audit.
- No uptime percentage and no service level agreement. There is no published measurement behind either, so neither appears anywhere on this site.
- No per-key daily limits. That field exists in the data model but the gateway does not enforce it, so it is not a control and we do not sell it as one.
Security FAQ
Can Iteradian see my API key?
No. API keys are hashed with HMAC-SHA256 before storage and the plaintext value is shown exactly once — at creation, or at rotation for the replacement key. If a key is lost it must be rotated, not recovered.
Can one organization reach another organization's data?
No. Every organization-scoped route authenticates the caller and then checks their membership of the organization named in the URL before the handler runs. A test asserts that both guards are present, in that order, on every such controller.
Does Iteradian store authentication tokens in localStorage?
No. The access token is kept in memory only, and the refresh token is an httpOnly, SameSite cookie that is rotated on use.
Can I restrict an API key to specific IP addresses?
Yes. Each key carries an IP allowlist of up to 50 addresses or CIDR ranges that the gateway checks on every request. The client address is resolved from a trusted proxy chain rather than from a header the caller controls. A key can also be limited to specific networks, given its own rate limit — which can only lower the organization’s limit, never raise it — and an expiry date; requests outside those restrictions are refused.
Is Iteradian SOC 2 or ISO 27001 certified?
No. Iteradian holds no SOC 2, ISO 27001 or PCI DSS certification or audit. The controls described on this page are implemented in the platform; any compliance requirement should be raised with sales before purchase.
Reporting a vulnerability
If you believe you have found a security issue, please email [email protected] with the details before disclosing it publicly. Please do not run automated scanning or load-testing tooling against production endpoints without written permission.