Loading…
PlatformPipeline, end to end
One pass. Every number. Evidence attached.
Upload a list and Bastro normalizes it, collapses it to unique numbers, checks each one against live registries, and hands back a clean file, a flagged file, and the record of both.
- UploadCSV, any layout
- MapColumns confirmed
- NormalizeE.164, every number
- DedupeUnique per job
- CheckLive registries
- ReportClean · flagged · evidence
IntakeUpload → E.164
A list arrives messy. It leaves canonical.
Drag a CSV in, in whatever shape your dialer or CRM exported it. You confirm which column holds the phone number and which columns ride along; nothing is guessed silently.
Every number is then normalized to E.164 at the parsing boundary — one canonical form, so every check downstream compares like with like. A number formatted three different ways across your file is one number to Bastro.
DedupeJob-scoped, by design
One check per unique number, per job.
Within a job, identical numbers are collapsed before any registry is queried — a number that appears 40 times in your file is checked once, and its verdict fans back out to all 40 rows in your report.
The scope is deliberate: dedupe lives inside the job, and nowhere else. Verdicts are never recycled across jobs or across customers, because a verdict is a statement about a number at a point in time — reusing last month's answer would quietly hand you stale data.
Representative job
Dedupe pass- Rows received
- 48,220
- Unique numbers
- 41,067
- Duplicate rows collapsed
- 7,153
- Registry checks run
- 41,067
ArchitectureChecked at job time
Bastro hosts no third-party registry data.
There is no mirrored litigator database sitting on our disks aging quietly. When your job runs, checks execute against vendor registries at that moment, through a vendor-agnostic adapter — so a verdict is as fresh as the registry the minute you pressed run, and swapping or adding a data vendor never changes your workflow.
0
Registry rows hostedQueried live, per job
1
Check per unique numberPer job — no cross-job reuse
100%
Verdicts stored with the jobYour audit record
TCPA litigator scrub
- Flags
- Known TCPA litigators and serial plaintiffs
- Backed by
- Vendor registry, queried at job time
DNC scrub
- Flags
- Federal and state Do-Not-Call registrations
- Backed by
- Vendor registry, queried at job time
Relocated number scrub
- Flags
- Reassigned, disconnected, and ported numbers
- Backed by
- Vendor registry, queried at job time
| Scope | Flags | Backed by |
|---|---|---|
| TCPA litigator scrub | Known TCPA litigators and serial plaintiffs | Vendor registry, queried at job time |
| DNC scrub | Federal and state Do-Not-Call registrations | Vendor registry, queried at job time |
| Relocated number scrub | Reassigned, disconnected, and ported numbers | Vendor registry, queried at job time |
The reportSummary · clean · flagged
Every job closes with its evidence.
A finished job produces three artifacts: a summary, a clean file ready for your dialer, and a flagged file where every row states its scope, the registry that flagged it, and the reason it was flagged.
Verdicts are stored per job as the audit record, and your job history is retained. Six months from now you can answer "was this number checked, when, and what came back" with a file, not a recollection.
Verdicts, as they appear
ClearedFlagged · LitigatorFlagged · DNCFlagged · Relocated
Scrubbing reduces measurable risk; it does not confer immunity. Querying the FCC's Reassigned Numbers Database carries a query safe harbor under FCC rules; litigator scrubbing carries none. See 47 CFR § 64.1200 for DNC obligations. Bastro provides data services, not legal advice.
API/resources/docs
The same pipeline, callable.
Everything above is one authenticated request away: submit numbers and scopes, get verdicts back. API-key auth, rate-limited, same job-scoped dedupe, same per-job audit record.
POST /api/v1/scrub
authorization: Bearer ba_live_************
{
"scopes": ["litigator", "dnc", "relocated"],
"numbers": ["+13125550142", "+16465550178"]
}