Does Stubsmith see my API request/response bodies?

No. The SDK encrypts samples at the edge before they leave your infrastructure. The Stubsmith server receives only ciphertext. Our staff cannot read sample bodies — this is a structural guarantee, not a policy promise.

What is the encryption key hierarchy?

Each organization has an encryption context bound to a KMS wrapping key. The wrapping key encrypts per-project data keys; those data keys encrypt individual sample payloads. Business plan organizations receive a dedicated KMS key for full isolation and crypto-shredding on offboarding.

What is crypto-shredding?

When a Business organization offboards, their dedicated KMS key is scheduled for deletion. Once deleted, all encrypted sample blobs become permanently unrecoverable — even by Stubsmith staff. No data needs to be located and deleted individually.

How does PostgreSQL RLS protect my data?

Every tenant query runs inside a transaction that sets an org_id context variable. RLS policies check this variable; a query without a valid context returns zero rows. The runtime database role has no BYPASSRLS privilege — fail-closed by design.

Where does my data physically reside?

Compute runs on Scaleway infrastructure in the EU (Paris/Amsterdam). Encryption keys are managed by Scaleway Key Manager in Amsterdam. DNS and CDN use Bunny.net, operated from Slovenia. No data is processed by US-headquartered hyperscalers.

Can I verify the security architecture independently?

The SDK is open source and the encryption path is auditable. The anonymizer rule format and the wrapping key schema are public. A third-party security audit is on the roadmap before the first Business-tier customer signs.

Security

The server never sees
your plaintext

Stubsmith generates privacy-safe API stubs from real traffic; samples are encrypted before they leave your infrastructure. This page explains how that works in practice.

Edge-only encryption

Samples are encrypted at the SDK — inside your infrastructure — before any network call is made. The Stubsmith ingest endpoint receives only ciphertext. The server has no key material to decrypt it.

This is the fundamental privacy guarantee: we never see plaintext request or response bodies, by construction. It is not a firewall policy, a RBAC rule, or a contractual promise that could be bypassed by a misconfiguration. The server literally does not have the private key.

The SDK applies your anonymizer rules (field masking, value redaction) before encryption, so sensitive fields you identify are removed even before the payload is encrypted. Two layers — anonymization first, then encryption.

Per-org KMS wrapping keys

Every organization's data is bound to its own KMS encryption context. The key hierarchy is:

KMS wrapping key (per-org or dedicated) — managed by Scaleway Key Manager in Amsterdam. Never leaves the KMS.
Project data keys — generated per project, wrapped (encrypted) by the KMS key and stored alongside the project.
Sample data keys — generated per capture batch, wrapped by the project data key. Encrypts the actual payload ciphertext.

Free, Solo, and Team plans share a platform KMS key but each organization has its own per-org encryption context — ciphertext from one org cannot be decrypted with another org's context even if the underlying KMS key is shared.

Business plans receive a dedicated KMS key. This enables a per-org decrypt audit trail in the KMS logs and crypto-shredding on offboarding: scheduling the key for deletion makes all encrypted blobs permanently unrecoverable without locating or deleting individual files.

PostgreSQL row-level security

Every database query runs in a transaction with an org_id context variable. RLS policies enforce org_id = current_setting('app.current_org') on every tenant table. A query without a valid context returns zero rows.

Fail-closed

The runtime database role has no BYPASSRLS privilege. A missing or invalid org context returns an empty result set — never another tenant's data.

Transaction-scoped context

The org context is set via set_config(..., true) — a transaction-local GUC. It is automatically cleared at transaction end. No cross-request leakage is possible.

FORCE ROW LEVEL SECURITY

All tenant tables have FORCE ROW LEVEL SECURITY enabled. Even the table owner role (used for migrations) obeys RLS policies during normal operation.

App-level filters too

Application queries also carry explicit WHERE org_id = ? filters. RLS is the backstop; application-level checks are the primary mechanism. Defense in depth.

EU-sovereign infrastructure

All Stubsmith infrastructure runs in the European Union. No data transits to or is processed by US-headquartered cloud providers.

Compute — Scaleway

API and ingest containers run on Scaleway Serverless Containers (Paris/Amsterdam region). Scaleway is a French company; infrastructure stays in the EU.

Encryption keys — Scaleway Key Manager, Amsterdam

KMS wrapping keys are managed by Scaleway Key Manager in the nl-ams region. Keys never leave the KMS; only decrypt operations cross the KMS boundary.

DNS and CDN — Bunny.net

DNS and CDN are operated by Bunny.net, a Slovenian company. We deliberately avoided Cloudflare (US, subject to CLOUD Act) for TLS termination.

Database — Scaleway Managed PostgreSQL

Customer data is stored in a managed PostgreSQL instance on Scaleway private network. Daily automated backups, no public endpoint, private-network-only access.

Sovereignty footnote: the .dev TLD registry is operated by Google. This is a paper-level dependency — the registry sees domain registration metadata, not user data or traffic.

Fail-closed fingerprints

A fingerprint is the structural signature of a request/response pair: method, path pattern, and response schema shape. It contains no payload data.

Fingerprints are capped per plan. When the cap is reached, new shapes are rejected at ingest with a clear error and a dashboard banner. The cap is enforced at ingestion time, not retroactively. Existing fingerprints and their stubs are never deleted.

Fingerprints are your durable asset. Samples (the encrypted payloads) expire on your plan's retention schedule. Fingerprints, request types, and generated stubs persist indefinitely.

Security FAQ

Does Stubsmith see my API request/response bodies?: No. The SDK encrypts samples at the edge before they leave your infrastructure. The Stubsmith server receives only ciphertext. Our staff cannot read sample bodies — this is a structural guarantee, not a policy promise.
What is the encryption key hierarchy?: Each organization has an encryption context bound to a KMS wrapping key. The wrapping key encrypts per-project data keys; those data keys encrypt individual sample payloads. Business plan organizations receive a dedicated KMS key for full isolation and crypto-shredding on offboarding.
What is crypto-shredding?: When a Business organization offboards, their dedicated KMS key is scheduled for deletion. Once deleted, all encrypted sample blobs become permanently unrecoverable — even by Stubsmith staff. No data needs to be located and deleted individually.
How does PostgreSQL RLS protect my data?: Every tenant query runs inside a transaction that sets an org_id context variable. RLS policies check this variable; a query without a valid context returns zero rows. The runtime database role has no BYPASSRLS privilege — fail-closed by design.
Where does my data physically reside?: Compute runs on Scaleway infrastructure in the EU (Paris/Amsterdam). Encryption keys are managed by Scaleway Key Manager in Amsterdam. DNS and CDN use Bunny.net, operated from Slovenia. No data is processed by US-headquartered hyperscalers.
Can I verify the security architecture independently?: The SDK is open source and the encryption path is auditable. The anonymizer rule format and the wrapping key schema are public. A third-party security audit is on the roadmap before the first Business-tier customer signs.

Privacy by construction, not policy

Start with the free plan. No card required.

Start free →See pricing

The server never seesyour plaintext