Privacy policy
POST Request delivers mailbox-access verification by U.S. mail. Two kinds of people appear in our records: customers, who hold accounts and call the API, and recipients, who receive a card at their address. This policy covers both. It is written to be checked against our conduct, not to reserve rights.
POST Request is operated by Jacob Shulman, an individual, in Washington State. “We,” “us,” and “our” mean him, operating as POST Request. Effective 2026-09-25.
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 do not request a recipient name or provide a recipient-name field. Do not put names or other personal data in customer-supplied reference fields. The scan page may show the sender’s display name, a masked bound email, and a return link to the sender.
Treat the QR link as a credential. Without email binding, anyone with the card or a copy of the link can complete the verification; no account sign-in is required. Email-bound cards also require a code sent to the bound email. If you did not request the card, do not scan, share, or confirm it; destroy the credential before recycling.
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, not a raw IP in the verification record. Infrastructure and processor logs require separate controls.
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.
| Mailing address ciphertext | Removed at terminal state + 90 days or earlier successful DELETE. Unresolved mail must first be reconciled; an in-flight webhook must finish. |
| Routine abuse observations | Keyed address/building identifiers, source/account/mode and mailing timing/count evidence. Expire 90 days after each event, including after an operational erasure request. |
| Address display + lookup signals | Display withheld on purge. Lookup signals expire 90 days after first creation or earlier DELETE; resends do not renew them. |
| Recipient name | Never collected. |
| Email ciphertext, if bound | Ciphertext and mask removed on purge. Keyed email hash follows the lookup-signal deadline. |
| External ID + metadata + return URL | Customer supplied. Removed on purge. |
| QR token | Hash on the verification, revoked on purge. Live dispatch artwork is encrypted until provider acknowledgment or scheduled deletion after 24 hours. Sandbox tokens are encrypted until purge. |
| Scan signals | Keyed IP hash. Removed at the lookup-signal deadline or earlier DELETE. |
| Saved webhook payloads + request-body digests | Removed after 90 days or earlier purge. Operation-key tombstones remain to prevent duplicate paid operations. An already in-flight webhook must finish before its saved payload is removed. |
Expired signals are unavailable to API reads even before background cleanup runs. Cleanup runs at startup and in bounded batches every ten minutes. Financial and operation receipts remain for accounting and duplicate-charge prevention. Application cleanup does not certify destruction of backups, old storage media or processor copies.
PP 04
Bounded abuse evidence, no research vault
We do not move purged addresses into a recoverable research vault. Minimal keyed mailing observations support abuse prevention for 90 days from each event. New activity does not renew older observations. These records remain linkable and are not anonymous. The operational encrypted address has its own schedule above.
Customer-facing address identifiers and reuse counts are scoped to that customer and test/live mode. Sandbox activity cannot query live counts. Separate internal keyed address signals support the cross-customer live mail-abuse limit; they are not exposed as a global address lookup or evidence that two accounts are one person.
There is no automatic indefinite-retention exception or reusable cross-platform identity product in this release. Any future portable verification service would require a separate design and opt-in. Backups and processors may hold copies; application erasure is not a guarantee of complete erasure everywhere.
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. Short-lived mail-request rate counters contain account ID, current-minute start/count and expiry, not address or request contents. Expired counters are removed by the bounded lifecycle cleanup.
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 request removal of application PII copies with DELETE /api/v1/verifications/:id/pii — this removes address/email fields, external ID, metadata, return URL, lookup signals, credentials and saved event, mail and webhook payloads. It revokes the card. Minimal abuse observations remain until their original 90-day expiry; financial and operation receipts also remain. Pending mail attempts must first be reconciled, and an in-flight webhook must finish. Already submitted mail and webhook deliveries cannot be recalled. The response explicitly does not certify deletion of backups or processor copies. For account deletion requests, email us; financial records needed for bookkeeping are retained. 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 records actually retained. Retained keyed abuse observations remain linkable to verification records; we do not claim they make customer or account linkage impossible.
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: [email protected]. Privacy requests may also be sent by mail to:
POST Request
720 Seneca St Ste 107
Seattle, WA 98101
This is a mailing address for correspondence, not an office.