What we do with your phone data
Plain English. Real numbers. No badges we have not earned. If a claim on this page is not backed by something specific in the product, it should not be here, and we want to hear about it.
At a glance
The two things people usually want to know first: what we do, and what we explicitly do not do.
- ·Encrypt in transit (TLS 1.2+) and at rest (AES-256 on object storage, managed disk encryption on Postgres)
- ·Cache lookups for 24 hours so repeats are free
- ·Delete batch CSVs and result files 90 days after upload
- ·Mask phone numbers in our internal request logs (first 4 and last 2 digits visible)
- ·Hash API keys and webhook secrets (SHA-256) and never store plaintext
- ·Honour data export and account deletion requests in-app
- ·Refund credits automatically on hard-fail upstream lookups
- ·Sell, share, or enrich your phone data for marketing
- ·Train models on your data
- ·Store the raw upstream response in long-lived logs
- ·Expose your data to other customers or to ad networks
- ·Promise per-country accuracy as a contractual guarantee
- ·Hide our subprocessors from you
Data handling
- Uploaded CSV. Sent to private object storage over TLS, encrypted at rest. Used to run the batch. Deleted from storage 90 days after upload (the
dataPurgedAtcolumn flips and downloads return 410 from that point on; the batch row stays so you still see it in your dashboard). - Result files. Same storage, same TLS and AES-256, same 90-day retention. Cleaning columns (full_results, sms_ready_only, etc.) are derived from your input, not from any cross-customer source.
- Lookup cache. Keyed by normalised E.164. 24-hour TTL from last access. Lets repeat lookups within a day be free. The cache stores the cleaning-column result, not the upstream raw payload.
- Provider request log. 90 days. Phone numbers are masked (first 4 and last 2 digits visible); the upstream raw response is sanitised before write so full numbers never sit in log rows.
- Webhook deliveries. Payloads and response bodies retained 30 days, then deleted. Enough for debug and manual redelivery, short enough to limit blast radius.
- Account deletion. Two-phase: request, 30-day reversal window, then a hard purge that scrubs PII (email, name) and removes API keys, webhook subscriptions, purchases, and idempotency keys. Anonymised analytics rows stay (Batch counts, ProviderRequest aggregates) so historic admin dashboards remain correct.
Full table with row-by-row retention windows is on the Data Policy page.
Encryption
- In transit
- TLS 1.2 or higher across the public API, the marketing site, the dashboard, and traffic to every subprocessor. HTTP redirects to HTTPS at the edge.
- At rest
- AES-256 on object storage. Managed disk encryption on Postgres. Backups encrypted with the same keys.
- Passwords
- Hashed by Lucia (Argon2-based via the Wasp auth layer). We never see plaintext.
- API keys and webhook secrets
- SHA-256 hashed on insert. Plaintext is shown once at creation; after that, even admins only see the 8-character prefix.
Subprocessors
Companies we share specific data with to deliver the service. If we add or change one, we update this list and (for paid accounts) email you. Last updated June 2026.
| Vendor | Purpose | Region | Data they see |
|---|---|---|---|
| Stripe | Payments and invoicing | US, EU | Billing email, card token, purchase history |
| Railway | Hosting, application runtime, managed Postgres | US | All operational data, encrypted at rest |
| Resend | Transactional email delivery (SMTP) | US | Your email address, subject and body of mail we send |
| Sentry | Server-side error monitoring | US | Stack traces and request context, with phone numbers masked before send |
| PostHog | Product analytics (in-app events only) | US | Anonymous interaction events; no phone numbers transmitted |
| Phone-data validation provider | Number validation, line type, carrier lookup | US | Normalised E.164 numbers only; identity available on request under NDA |
Verify these claims
A claim is only as good as the way you can check it. For every promise on this page, here is how you (or your security team) can see for yourself that we are doing the thing we say.
| Claim | Type | How to verify |
|---|---|---|
| TLS 1.2 or higher on every public endpoint | Third-party | Run Qualys SSL Labs against phonelistcleaner.com. You should see TLS 1.2 / 1.3 only. |
| 24-hour lookup cache, repeats are free | Self-check | Run the same number twice within 24 hours via POST /v1/lookup. The second response includes cached: true and no credit is charged. |
| Phone numbers masked in our internal request logs | Self-check | The masked format is +1234***56 (first 4 plus last 2 visible). Any support ticket about a specific number cites it that way; full numbers never appear in our reply. |
| Upstream raw response is sanitised before write | Self-check | Ask support to retrieve a ProviderRequest row for a lookup of yours. The response JSON returned will contain only masked phone strings. |
| Batch files and result CSVs deleted after 90 days | Self-check | After 90 days, the batch row in your dashboard shows a "Data expired" state and download links return HTTP 410 batch_data_expired. You can test this on any batch older than 90 days, or request a manual purge from hello@phonelistcleaner.com. |
| API keys stored as SHA-256 hashes, never plaintext | Self-check | Create an API key in the dashboard. The plaintext value is shown exactly once at creation and is never recoverable, even by support. After creation, only the 8-character prefix is displayed. |
| Credits refunded automatically on hard-fail upstream lookups | Self-check | The Billing page lists every ledger entry, including provider_failure_refund rows tied to specific batches. |
| Webhook deliveries deleted after 30 days | Self-check | The Webhooks page only shows deliveries from the last 30 days. Older deliveries return a "no longer in retention" notice on redelivery attempts. |
| Account deletion purges PII after a 30-day grace window | Self-check | Account > Danger zone > Delete account. Triggers the two-phase flow. You can cancel during the grace window; after it, request your own data export to confirm scrubbed rows. The code path is the same for everyone. |
| We do not sell or share your phone data | Self-check | There is no data SKU on the pricing page. The subprocessor list above is exhaustive: nobody else receives your numbers. Acceptable Use Policy bans us from doing so. |
| We do not train models on your data | Internal | We do not ship a machine-learning product, do not run a model-training pipeline, and do not contract this work to a vendor. Auditable on request: we will demonstrate the absence of training infrastructure on a screen-share for paid customers. |
| Encryption at rest on object storage and Postgres | Third-party | Object storage encryption follows the platform default (AES-256). Postgres uses Railway-managed disk encryption. See Railway's security page. |
Type key. Self-check means you can verify it yourself in the product. Third-party means an independent tool or the provider's own published documentation backs it. Internal means we can demonstrate it on a screen-share for paid customers; we will never ask you to take it on faith alone.
Country coverage
We accept E.164 numbers globally. Cleaning accuracy and the availability of carrier and line-type signals vary by country. Mature markets (US, Canada, UK, Australia, most of the EU) are typically 95%+ accurate on line type. Other countries return best-effort data. None of this is a contractual guarantee.
Per-country breakdown lives in the FAQ. Edge cases (VoIP, ported numbers, freshly-issued blocks) are inherently noisy and we say so up front.
Report an issue
One mailbox, one human at our scale. We acknowledge within two business days. Tell us what you found and how to reproduce it; we will take it from there.
Use this address for every kind of report: security vulnerability disclosures, data export or deletion requests, GDPR / UK GDPR subject rights, DPA requests, suspected abuse of our service, stuck batches, billing questions, anything else. Put the topic in your subject line and we will route it internally.
Public security policy: /.well-known/security.txt. Coordinated disclosure preferred; we credit responsible reports here on the Trust page.
Legal and status
Need a DPA, security questionnaire response, or a copy of our sanitised internal data-flow doc? Email hello@phonelistcleaner.com.