Privacy policy

PP 01

If you received a card

A website you use asked us to confirm that its user can receive mail at your address. The card shows no name — it is addressed to CURRENT RESIDENT — and, unless the sending platform chose to identify itself on the message side, nothing on the card says which platform sent it.

We never learn or store a recipient’s name. The API that creates a mailpiece does not accept one. Scanning the card’s QR code opens a page that reveals nothing about the account or platform behind it. If you did not expect the card, you can recycle it; it is useless to anyone who does not also control the account that requested it.

PP 02

Verification records

A verification record holds the mailing address (encrypted at rest), the mail class, timestamps, and abuse signals computed at creation: a keyed address fingerprint, a building-level cluster key, and PO-box detection. When the card is scanned we record a keyed hash of the network address and a three-digit ZIP region — never the raw IP, never a precise location.

Fingerprints are keyed HMACs under server-held keys, not bare hashes. The U.S. address space is public and small enough to brute-force; an unkeyed hash of an address would be plaintext with extra steps, so we do not make one.

PP 03 · Form PS-110

The records schedule

Retention is a schedule, not a promise to think about it later.

PP 04

The delinked vault, and what it cannot answer

Ninety days after a verification reaches a terminal state, the address leaves the operational record and enters a separate encrypted vault holding the address, week-level date, mail class, and abuse flags — no customer ID, no verification ID, no status trail, no precise time. The only path that could re-link a vault row to a verification is a separate server key whose every use is logged.

This is the design assumption made explicit: we judge every retention decision by what a thief who copies the database gets. The dangerous artifact is not an address — addresses are public — it is the linkage of account, platform, address, and time. The vault exists so fraud research can ask “has this address pattern appeared before?” without anyone being able to ask “who verified at this address, on which platform?”

One residual disclosure survives this design, and we state it rather than hide it: a stolen vault reveals that a household verified with some service, at week precision, within the last 18 months. It does not reveal which service or which account.

PP 05

Customer accounts

An account holds your email address, API key hashes, webhook configuration, and the credit ledger. Payments are processed by Stripe; we hold a Stripe customer reference, never card numbers. Sign-in uses one session cookie. There are no analytics cookies, no advertising identifiers, and no third-party trackers on any page — including the verification page recipients see. We count page views ourselves, first-party and cookieless: one counter per day, path, and referring site, honoring Do Not Track, storing no IP addresses and no visit records.

PP 06

Who touches the data

Four parties process data on our behalf: Lob prints and mails the physical cards (it receives the address — it must — and no recipient name, because none exists); Stripe processes payments; Resend delivers transactional email (sign-in codes, verification codes, balance alerts); and our server host, where the encrypted database lives in the United States. We sell nothing to anyone: no data sales, no ad networks, no “partners.”

PP 07

Erasure

Customers can destroy the personal data on any verification immediately with DELETE /v1/verifications/:id/pii— it runs the purge and vault graduation on the spot instead of at day 90. Account deletion: email us and we delete the account; the ledger’s financial records are retained as required for bookkeeping. Recipients who want a verification’s data removed can ask the platform that sent the card, or contact us directly with the card in hand.

PP 08

Legal process

We respond to valid legal process. What that process can obtain is bounded by the schedule above: after the purge window, the systems cannot produce a recipient name (never held), a plaintext address on the verification (vaulted), or an answer to “who verified at this address, for which platform” from the vault alone. We designed the records so that the honest answer to many demands is that the record does not exist.

PP 09

Changes and contact

Material changes to this policy get a revision code, a dated note here, and email to customers before they take effect. Questions, erasure requests, or anything else: jake@postrequest.dev.