Build versus buy
One validation contract across every client you maintain
Six client codebases, six validation layers. One does phone with a library, one does email with a regex somebody wrote in 2021, two do both differently, and each returns a different shape to a different piece of downstream code. When a numbering plan changes or a registry reallocates a range, the fix happens in whichever of them somebody remembers.
The alternative is one endpoint that returns the same shape for phone, email, IP and domain, with the evidence and its source attached, and a stated outcome when the evidence is thin. Below is exactly what that includes, and the parts of it that do not exist.
Integration constraint, before anything else
The API is server to server only. It sends no CORS headers and refuses a browser preflight, so it cannot be called from browser JavaScript.
Your client’s form posts to your server, and your server calls Orisift. If a client project is a static site with no backend, that project needs one before this is usable in it. A key in front-end code would be readable by every visitor and is a credential for the whole account, which is the other half of the same reason.
Three responses, one shape
Real output, not examples. The same fields in all three, including the two where the answer is uncomfortable.
1. A number that passes every format check and is still unusable
Correctly formed, matches the numbering plan, and sits in the range NANPA reserves for fictional use.
This phone number will not work
- verdict
- rejected
- risk_score
- 64
- evidence_coverage
- 72
- credits
- 1
recommendation
Do not accept this phone number. Ask for a replacement at the point of capture.
| Capability | State | What it says |
|---|---|---|
| Format | VERIFIED | Parsed successfully |
| Plan validity | FAILED | Matches the national numbering-plan pattern, but the range is not assignable: NANPA reserves 555-0100 to 555-0199 for fictional use. |
| Carrier | NOT OFFERED | Orisift does not currently contract a carrier-data provider, so the operator of this line is not looked up. |
| Reachability | NOT OFFERED | Nothing here dials or pings the number. Plan validity is not evidence that a line is active or reachable. |
2. Mail routing that passes, with mailbox existence still refused
A real address on a real domain. Format, infrastructure and reputation all verified, and the check still declines to say the mailbox exists.
Evidence supports this email address
- verdict
- verified
- risk_score
- 0
- evidence_coverage
- 88
- credits
- 1
recommendation
Safe to accept and pass downstream.
| Capability | State | What it says |
|---|---|---|
| Format | VERIFIED | Address structure is valid |
| Infrastructure | VERIFIED | Domain publishes mail exchangers |
| Reputation | VERIFIED | Not on the disposable list |
| Reachability | NOT OFFERED | Orisift does not probe SMTP, so it cannot confirm this mailbox exists, is monitored, or will accept mail. Domain-level routing is as far as the evidence goes. |
Role mailbox
"support" is a conventional shared mailbox name, so this probably reaches a team rather than a named person. That is a fact about the mailbox, not a concern.
no_mailbox_verification— Mailbox existence is not verified. See /coverage.
3. A missing parameter, which is not the same as a bad number
A national-format number sent without a country. The response carries no score at all, because there is nothing to score.
Not enough evidence to judge this phone number
- verdict
- insufficient_evidence
- risk_score
- null
- evidence_coverage
- 0
- credits
- 1
recommendation
Retry shortly. If it stays inconclusive, treat the identifier as unverified rather than bad.
| Capability | State | What it says |
|---|---|---|
| Format | NOT AVAILABLE | Cannot parse without knowing the country |
| Plan validity | NOT AVAILABLE | Cannot validate without knowing the country |
| Carrier | NOT OFFERED | No carrier provider is contracted |
| Reachability | NOT OFFERED | No reachability provider is contracted |
country_required— A national-format number needs an explicit country. See /docs.
Worth wiring for on day one: an integration that treats this as a rejection turns away real customers over a parameter its own request left out. It still costs a credit.
What does not exist
None of this is on a roadmap here. If any of it is a requirement, this is not the product for that requirement yet, and finding that out now is cheaper than finding it out in month two.
Per-client separation
One account. Keys are labels, not boundaries: any key can look up anything, and there is no way to scope one to a project.
Per-client billing
One shared credit pool across everything. There is no split by key, no per-client invoice and no usage report you could hand to a client as a bill.
An agency dashboard
One dashboard for the account. No client list, no sub-accounts, no seats, no role separation.
What does exist: one account, one shared credit pool, and up to 20 API keys with no configurable scopes. Enough to give each client project its own key so you can see which one a request came from and revoke one without touching the rest, and not enough to be a separation boundary.
What it costs, including the answers you might not want
A rejected lookup costs a credit
The work was done and the answer is the product.
An inconclusive lookup costs a credit
Including a national-format number sent without a country.
A domain costs two
Phone, email and IP cost 1. Domain costs 2.
500 credits on signup, once, with no card. Plans from £19 a month for 20,000 credits. All plans and currencies.
Test it against a real client requirement
Three checks a day with no account. Use the values above, or something from your own stack, and read what comes back before you decide anything.
Questions that need a person: support@orisift.com reaches the founder directly. The phone side in more depth is on the phone validation page, and the coverage matrix lists every capability by country.