What leaves your network

Violation fingerprints and one redacted example per fingerprint per window. Never a full request or response body. This page exists because that sentence deserves more than a line in a DPA.

Fingerprints

A fingerprint identifies the shape of a violation, not its content: the operation, the schema pointer, the class of error. "POST /pets rejected because name is missing" is one fingerprint however many million times it happens; the drift report counts occurrences against it rather than storing them.

This is also the cost model working in your favour: an API with a permanently broken endpoint produces one fingerprint and a counter, not a stream of stored failures.

The one example

Counts alone do not fix bugs, so each fingerprint keeps a single example per reporting window - with values redacted before it is stored. Field names survive; field contents do not. Enough to see which property violated which constraint, never what a customer typed into it.

The counters

Two more things travel on the same channel, and this page would be incomplete without them.

Request counts, per proxy per hour. That is the meter your invoice is built from. It is a number, not a log: no paths, no clients, no timing.

Coverage counters, per operation. How many responses were seen, how many were checked, and the named reason for each one that was not - the numbers behind the coverage page. Operation ids come from your document, which you wrote; nothing in them comes from a payload.

Both are counters, both are aggregates, and both are shipped on the same token and the same retry story as the fingerprints.

What we never see

• Request and response bodies, beyond the single redacted example above, and the relay described below.
• Credentials: Authorization, Cookie and friends are stripped before a violation record is even assembled.
• Anything at all from conforming traffic. A request that matches the contract is forwarded and forgotten; only its counter survives.
• Query strings, paths and headers of individual requests. A fingerprint names the operation your document declares, never the URL somebody called.

The one exception, and you press it yourself

The test console on a proxy's page sends real requests to your API, and it sends them through us: you click a button on openapi-proxy.com, our server makes the request to your gateway, and the answer comes back the same way. For those requests, and only those, the full body passes through our process.

It is not stored, not logged and not sampled - it is relayed and dropped, the same as conforming traffic - but "we relay it" is a different sentence from "we never see it", and this page would be worthless if it did not say so.

Nothing does this on its own. It happens when somebody signed in to your account presses a button on a page that says, above the buttons, that the requests are real.

Need isolation?

A dedicated instance runs your gateway single-tenant on isolated infrastructure we operate, in the region you choose - no other customer on the same machine. The data that reaches our control plane is the same fingerprint stream this page has already described; what changes is that the instance is yours alone.