Numverify
Analytics & DataValidate and look up phone numbers across 232 countries and territories with Numverify by APILayer. Agents confirm a number is real and identify its carrier and line type before a message is sent.
What This Integration Enables
Numverify is deliberately narrow, and that is the point. It exposes one lookup and one reference list. There is no account surface, no credit endpoint, no bulk pipeline, and no portability layer. What it does is answer, in a single real-time call across 232 countries and territories, whether a number is valid and what it is: local and E.164 formats, dialling prefix, country code and name, location or city, carrier name and line type. That makes it the validator you put directly in front of a form field, where the cost of the call is a few hundred milliseconds and the payoff is that a bad number never enters the system at all.
Agents use it in three shapes. As a gate at capture, rejecting or correcting a number before the record is written. As a router, reading line type so the workflow sends an SMS to a mobile and places a call to a fixed line rather than assuming. As a signal, flagging a number whose country does not match the rest of the submission. Get Supported Countries backs all three by returning the full coverage list keyed by ISO country code with each country's dialling code, which is what a country picker or a prefix-to-country resolver should be built from instead of a hard-coded table. FlowRunner's connectors are built and verified against the vendor's official API, so the fields the agent reads are the fields Numverify documents.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Gating a signup form
A signup form posts a phone number. Before the record is created, the agent calls Validate Phone Number with the international number, or with the national number and a Country parameter when the form collected them separately. Invalid numbers come back with everything except the number itself null, and the agent returns a field-level error to the form rather than accepting a value it knows is broken. Valid numbers are written in E.164 into HubSpot with the local format kept alongside for display. Deduplication stops being a project because everything arrives in one shape.
Routing outreach by line type
An outreach sequence has both a text step and a call step. The agent validates each contact once, reads the line type, and splits the audience: mobiles get the SMS through ClickSend, fixed lines skip it and go straight to the call task. Carrier and location come back in the same response and get written onto the record, so a rep opening the contact sees the region before they dial rather than after.
Cleaning numbers that were captured before validation existed
Numbers collected over years sit in the CRM in whatever shape they arrived. A scheduled flow walks them in batches, validates each one, and writes back the E.164 form, the country, the carrier and the line type. Numbers that fail outright are marked for review rather than deleted. The result is a contact base where the channel decision is data rather than a guess, and where the invalid records are visible as automation exceptions instead of silently failing at send time.
Human-in-Loop Highlight
Numverify documents something most workflows quietly ignore: location, carrier and line type are not available for every number, and when they are not, the fields come back null. Null is not landline. Null is not VOIP. Null means the API did not have that attribute for that number, and the number may be a perfectly good mobile belonging to a customer who has been buying from you for six years. An agent that treats a null line type as "not a mobile" will suppress those people from SMS, and because the suppression looks like a correct data-driven decision, nobody will ever audit it. So the agent does not decide. It routes confirmed mobiles and confirmed fixed lines automatically, then collects the null group and puts it in front of the channel owner: "412 numbers validated, line type unavailable. 388 of them have opened SMS from us before. Send anyway, hold for email fallback, or leave them in the SMS audience untouched?" The owner answers once, the rule is recorded, and the agent applies it. The verdict the API refused to give is not one the agent invents on its behalf.
Agent Capabilities
2 actionsPhone Validation
1- Validate Phone Number Validates a phone number and returns full carrier and location intelligence for it. Accepts an international number, where the country is detected automatically, or a national number combined with a Country parameter. Reports validity plus local and E.164 international formats, dialling prefix, country code and name, location or city, carrier name and line type. Location, carrier and line type are returned as null where the API does not hold them, and for an invalid number only the number itself is echoed back. Covers 232 countries and territories.
Reference Data
1- Get Supported Countries Retrieves the full list of the 232 countries and territories supported for validation, keyed by ISO 3166-1 alpha-2 code with each country's name and international dialling code. Used to build country pickers, to resolve a dialling code back to a country name, and to confirm coverage before validating national-format numbers.
Frequently Asked Questions
What can FlowRunner do with Numverify?
FlowRunner agents can run Validate Phone Number and Get Supported Countries in Numverify.
Does connecting Numverify to FlowRunner require OAuth?
No. Numverify connects to FlowRunner with an API key, no OAuth flow required.
Can Numverify trigger a FlowRunner workflow automatically?
Numverify doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Numverify
$100 in credits. No card required. Connect in minutes.