Security

Security, documented like
an engineering page.

What we store, what we don't, how auth actually works, and exactly where our compliance posture stands today. If anything here is unclear, security@richapi.ai answers.

1 Keys & auth

How it actually works.

REST: per-workspace API key in the x-api-key header. Rotate from the dashboard; revocation is immediate.
MCP via OAuth (claude.ai connectors): the bearer token your client stores is an HMAC-signed grant — never the raw API key. Disconnecting from your dashboard revokes it; revocation propagates to the edge fast (design target: ≤60 seconds).
Every MCP connection writes an audit row: when connected, from which client, last used.
Per-request isolation:each customer's calls execute under their own credentials by construction; the code path that could mix tenants throws by design. (Yes, our architecture docs say “billing/data isolation invariant” — we treat it as one.)

2 Data flow & retention

What we store, and for how long.

Lookup inputs (names, domains, URLs, emails you submit): processed to execute the call, retained in request logs for [N] days for billing/debugging, then purged. (Publish the real N at build time.)
Results: returned to you; web-scraping endpoints cache results server-side (Redis) for performance — paid-provider lookups are fetched live.
Logs:structured, correlation-ID'd, with an automated zero-plaintext-PII policy — secrets and personal data are scrubbed before anything is written.
Your account data: email, billing records, usage ledger — retained for the life of the account + statutory accounting periods (Estonian law: 7 years for invoices).

3 Provider chain (subprocessors)

Every response names the provider that answered.

Waterfall lookups execute against licensed third-party data providers; the provider field in every response tells you which one answered. Infrastructure: AWS (API, EU region), Cloudflare (MCP edge), Supabase (auth/audit), Stripe (payments), Sentry (errors, PII-scrubbed). Full subprocessor list with purposes maintained here; changes announced 30 days ahead via changelog.

4 Reliability controls

Circuit breakers, rate limits, signed webhooks

Provider circuit breakers with auto-recovery · per-customer rate limiting with atomic accounting and refund-on-failure · idempotent retry semantics (hard fails bill nothing) · HMAC-signed webhooks (X-RichAPI-Signature) · 517-test CI gate on every deploy · public status page with incident history: status.richapi.ai.

5 Compliance posture

The honest table.

Item	Status today
SOC 2 Type II	Observation window opens July 2026. Controls documentation under NDA now; report shared on issuance.
GDPR	EU-headquartered (Tallinn, Estonia). DPA available. Legitimate-interest assessment on file for B2B contact processing. Deletion requests honored and propagated to caches: `privacy@richapi.ai`.
Data residency	API processing in AWS EU region; MCP edge on Cloudflare's network. Enterprise: residency commitments in the MSA.
Pen test	Scheduled within the SOC 2 program; summary available to Enterprise under NDA when complete.
PCI	Card data never touches our servers — Stripe-hosted checkout.

Rule we hold ourselves to: nothing appears in this table before it's true.

6 Data ethics

The paragraph every buyer quietly looks for.

RichAPI processes business-context data: professional profiles, company records, work emails. We buy from licensed providers rather than operating gray-area collection, we don't sell or republish bulk datasets, we don't build public people-directories, and we honor removal requests downstream. The enrichment industry has seen what the other path looks like — we're built to still be here in five years.

7 Responsible disclosure

Good-faith research is welcome.

security@richapi.ai · acknowledgment within 2 business days · no legal action for good-faith research · hall-of-fame credit on request. PGP key published here.

Need the DPA or a security review?

Request the DPA Security questionnaire? → contact sales

Security, documented likean engineering page.