Your product. Your customer. Our filing engine.

The scan returns a real personalised result: whether the subject is exposed, where, what categories of data are held, and a risk band. It is synchronous, and it does not require an account. Asking a user to commit before you have shown them anything is the largest leak in this funnel, which is why the endpoint answers first.

Two passes run underneath. Sources we can query directly are checked one by one and are the only ones that can ever be reported clean. Alongside that, a search layer checks a much larger and continually growing set of broker domains for a listing. Because it matches one query against the whole domain list, widening that set costs nothing per scan, which is why it keeps growing.

A search hit proves a listing. A search miss proves nothing, so those domains can report found and are never counted toward a clean result. Findings that come from the search layer are also capped at a lower match confidence, so your interface can tell a strong match from a probable one.

Known-breach exposure is looked up in the same call, so a result can cover both where someone is listed and where they have already been leaked.

Detection and removal are different surfaces. You do not have to find a listing to file against the company holding it, and the filing catalogue is much larger than the set of sites anyone can search.

The catalogue is built from public state broker registries, which are government records and carry a compliance contact and a rights URL by law. Each target is matched to the statute that applies to your subject, and to that broker's own stated requirements for what a request must contain.

Where several brands sit under one parent, one filing covers all of them, because they share a compliance address. The catalogue is deduplicated on that basis rather than inflated by counting brands.

Each request is addressed to the broker's registered compliance contact and asserts only the rights the subject's own state actually grants. A California subject gets deletion, opt-out of sale and suppression on that state's response window. A Nevada subject gets opt-out of sale, because Nevada grants no deletion right, and a deletion request goes alongside it as an explicitly voluntary courtesy rather than a false demand.

That distinction is not decoration. A blanket California letter filed for a subject who does not live there asserts a residency that is not true, and a broker is entitled to reject it on exactly that basis.

Per-broker behaviour is data rather than code: what a given broker requires, how it confirms, whether it accepts a delegated confirmation, and how many attempts are reasonable. Nothing is sent speculatively. Where a broker needs an identifier we hold below our confidence floor, the request is held and the job says what it needs rather than filing a stranger's details.

A sent request is not a completed one, and the gap between those two things is where this category loses people's trust. Broker replies come back to a per-job address, are checked against the broker's own domain and known compliance address, and are classified before they move anything. Anything failing those checks moves nothing.

A broker saying "done" is not the same as it being done. A confirmation puts the record at provider_attested. Only an independent rescan moves it to scan_verified. Most of this market reports both as "removed"; your customer gets to see which one they have.

This is where removals quietly fail. A broker demands a piece of verification the request did not carry, nobody answers, and the request dies without ever being refused. It never shows up as a failure because nothing failed.

A demand like that becomes a real state on the record, carrying the field required, the reason, which broker asked and the statutory deadline for answering. You pass the answer back through one call and we reply inside the existing thread with that broker, so the exchange continues rather than restarting.

Brokers re-list. A record that was verified absent can reappear months later from a fresh data purchase, and a product that swept once and stopped will be quietly wrong about its own customer.

The re-check loop rescans on an interval, and a reappearance moves the record back to filed automatically. That cycle is the reason a removal product renews. It is also the part your subscription is actually selling, so it is worth making visible in your own interface rather than leaving it running silently.

A re-check that cannot read the page returns unverified and changes nothing. A broker having a bad day is not evidence that someone was re-listed, and it must never be allowed to downgrade a removal you have already confirmed to your customer.