Skip to content
personablocks.io PersonaBlocks Docs

Data minimization

The API is built to hand you a decision, not a data dump. Responses are hand-picked public shapes: each one exposes only the fields a merchant integration needs to act, and omits everything else at the source rather than redacting it after the fact.

What responses never contain

Section titled “What responses never contain”

No /v1 response — and no webhook payload — ever carries:

  • Personal names. First and last names are never serialized into any public shape.
  • Screening, sanctions, or SAR content. The compliance work behind a decision stays server-side.
  • Raw evaluation detail. The full decisioning breakdown that produced a status is never returned.
  • Secrets or hashes. API-key hashes, client-token hashes, and webhook signing secrets never appear in a read response. (A newly created key or webhook secret is shown exactly once, on the create call that mints it, and never again.)

Where the underlying record holds more than the public shape allows, the API simply doesn’t include it.

This is a deliberate consequence of the model: PersonaBlocks does the sensitive compliance work — the screening, the biometrics, the decisioning — and hands your integration the smallest result that lets you act. You get to gate access on a verified status without ever taking custody of the raw material behind it, which keeps that data off your systems and out of your compliance scope.

Enforced, not just intended

Section titled “Enforced, not just intended”

Minimization isn’t a per-request option you can turn off. The every-response guarantee is structural: each response is built from a hand-picked serializer that exposes only its public fields, so sensitive data never enters an outgoing body in the first place. On top of that, an automated deep-scan safety net (assertMinimized) enforces the forbidden-key list — the test suite runs it over every response shape, at every depth, so a serializer that ever leaked one of those keys would fail before it shipped.

The browser sees even less

Section titled “The browser sees even less”

The Web SDK’s onComplete callback runs in the customer’s browser, so it’s the most constrained surface of all. It receives IDs only:

onComplete: ({ sessionId, vicId, method }) => {
  // sessionId, vicId, method — nothing else.
}

No verdict, tier, score, or evaluation data ever rides this callback. Anything beyond the bare IDs is a server-to-server concern: your backend learns the outcome from the signed verification_session.completed webhook (or by reading the session over the API), never from the frontend. This keeps decisioning data off the client entirely, even from your own page code.

Section titled “Related”