What we hold, and on whose authority.
This page describes how the platform actually handles subject data. It is written to be checkable against the system rather than to be reassuring.
Our role
The partner is the authorized agent for the subject and holds the subject's authorization. We are the technical executor: we act on instructions issued through the API, against targets the partner's job specifies, on behalf of a subject whose consent the partner obtained and retains.
We never store the signed authorization document. A job carries only its reference, hash, signing date and issuer. The document itself stays with the partner, which is the correct place for it and keeps our copy of the relationship minimal.
What is held, and for how long
Subject details, partner-supplied credentials and discovered profile URLs are encrypted at rest with AES-256-GCM. The subject identifier used for audit is hashed and not reversible. API keys are stored as an HMAC, never in plaintext.
Retention is purpose-based rather than a single global window. Data held for a job is released once it no longer serves that job:
| Job outcome | Address candidates held |
|---|---|
| Scan only | 7 days |
| Failed or cancelled | 1 day |
| Completed removal campaign | 90 days |
The free scan holds no raw subject data at all. Its cache key is a hash, and the window is 48 hours.
Erasure
A subject's data can be erased across every store that holds it, on request through the partner. That covers the job record and the removal audit rows that cascade from it, and reports the mail addresses holding any related correspondence so those can be purged too.
Outbound requests
Requests we file on a subject's behalf are statutory deletion and opt-out requests, sent to the compliance contact each broker publishes as a matter of public record. Replies are checked against the broker's own domain and its known compliance address before they are allowed to change anything, so a forged reply cannot move a record or extract data.
Security posture
Every partner-supplied URL is validated against SSRF before it is used, and a webhook URL is re-validated before each delivery rather than only at registration. Webhook signing secrets are per customer. Every customer-facing query is scoped to the calling key's own records.
We hold no third-party security certification and do not imply one. The controls described here are the ones the system implements, and they are described in more detail in the documentation.
Terms, DPA and agent policy
Contractual terms, the data processing agreement and the authorized-agent policy are issued per partner as part of onboarding. Ask for them at any point in an evaluation, including before you integrate.
Contact
Privacy and data-handling questions: [email protected].