Security and data handling

Phone numbers and e-mail addresses are personal data, and we handle them that way. Identifiers are encrypted when stored and masked wherever people see them. They are kept only for short default periods, and your cache is never shared with other customers. Anyone can object to being checked. This page describes these controls in plain terms. It is not a certification.

#How are phone numbers and e-mails stored?

Identifiers are sealed with public-key encryption as soon as they are stored. The services that take requests can encrypt, but they can't decrypt. Decryption keys are only held by the internal component that has to run the check.

To find repeat checks and apply the suppression list without decrypting anything, we use a keyed blind index. That is a one-way keyed hash of the normalized identifier, and without the secret key it can't be reversed or recomputed. Results are sealed per item as well.

Before anything is stored, phone numbers are normalized to E.164 and e-mail addresses are trimmed and lowercased. This means one identifier maps to exactly one record. Connections to the API and the website use TLS.

#Who can see the data?

Almost no one sees full identifiers. Logs, the admin panel, job results and downloads show masked values, such as +44770*****01 for a number or re•••@example.com for an address. We never put phone numbers or e-mail addresses in URLs or request headers, because those end up in access logs. The API only accepts them in request bodies.

API keys are stored as keyed hashes and shown only once, when they are created. You can limit a key to certain scopes, and you can restrict it to your own IP addresses with an allowlist that accepts IPv4 and IPv6 ranges. Unknown, revoked, expired and wrong-IP keys all get the same unauthorized answer, so the error doesn't reveal which case applies. Staff access to the admin panel goes through an identity-aware access gateway and every action is audited.

#How long is data kept?

You can delete a finished job's data before the retention period ends with DELETE /v1/jobs/{id}. Cached answers live in your account's cache only and are never shared across customers. Billing records keep counts and amounts, not identifiers.

#How can people object to being checked?

People whose number or e-mail address may be checked, and people whose number may appear in spam-report data, can use the opt-out form. We review every request. An approved objection puts the identifier on a suppression list, which is checked before every lookup. A suppressed identifier is never checked and shows up in results as suppressed, free of charge. The form's reply is the same in every case, so it never confirms whether we hold data about someone. Requests for access or erasure are handled as described in the data-subject notice.

#Which sub-processors do you use?

We use sub-processors in these categories:

• hosting and infrastructure
• storage and backups
• e-mail delivery
• payments
• data-verification partners that answer individual checks

The named list is given under confidentiality to every customer who signs our data processing agreement. Changes are notified in advance and you can object to them. Partners receive only what a check needs, which is the identifier and the service, and never your account details.

#What else protects the service?

• Abuse controls. Requests that look like sequential number ranges or generated e-mail lists are rejected, and each account has a daily cap. See rate limits and abuse.
• No profiling outputs. Checks answer yes, no or unknown, plus defined data fields. We never return names, photos or profiles.
• Signed webhooks. Every delivery is signed and only goes to public HTTPS endpoints that you have verified.
• Cookies. The site uses no analytics or advertising cookies. See the cookie notice.

To report a vulnerability, use the contact in /.well-known/security.txt.