Security

This page summarizes security properties developers and procurement teams care about. Detailed webhook mechanics, code samples, and retry behavior are in Webhooks; async URL rules are also covered on Email verify — Webhook.

API keys and transport

• Email verify and Management endpoints expect a Bearer token over HTTPS (TLS). Do not send keys in query strings or client-side logs.
• Standard keys (sk_live_... / sk_test_...) are for verify routes; provisioning keys (sk_mgmt_...) are for Management API only. Rotate and revoke keys from the dashboard or via management routes.

Webhook integrity (HMAC)

When you set webhook_secret on a verify request, each callback can include X-Truval-Signature: sha256=<hex>, computed as HMAC-SHA256 over the raw JSON body. Verify the MAC before trusting the payload.

Full algorithm, receiver checklist, and language snippets: Webhooks — HMAC signature.

Webhook transport and SSRF safety

Callbacks are only issued to URLs that pass validation: HTTPS, hostname (not a raw IP), no user credentials in the URL, and not localhost or *.local. The worker does not follow redirects. That reduces common SSRF and metadata-credential risks; see Email verify — Webhook for the full rules and residual considerations.

Data residency and processing

Primary application data (for example account state and usage metadata backing the dashboard) is hosted in the European Union — for example Supabase in Frankfurt, Germany.

Network edge processing may occur globally (for example API delivery, caching, and security controls via providers such as Cloudflare). Verification inputs are processed to produce results; treat sensitive payloads according to your own compliance needs.

Formal legal terms, sub-processor locations, and processing details:

• Privacy policy
• Data Processing Agreement (DPA)
• Sub-processors

Related

• Webhooks — retries, backoff, dashboard logs
• Uptime and reliability — availability expectations