canonical: https://jentic.com/apis/numverify.com/numverify # numverify API Jentic publishes the only available OpenAPI specification for numverify API, keeping it validated and agent-ready. numverify is an apilayer-hosted phone-number validation and lookup service that returns line type, carrier, country, and location for an international phone number. The API exposes a single GET endpoint that accepts the number and an access key as a query parameter and returns the enriched JSON result. It is used by signup forms, marketing-list cleansers, and SMS routers that need a fast yes-or-no validity check plus basic carrier metadata. ## For AI agents Validate an international phone number and return its country, carrier, line type, and location through a single GET call. ## Scope Does not send SMS, place calls, or perform identity verification - use for phone-number validation and carrier enrichment only. ## Capabilities - Validate an international phone number and return its country code - Return the carrier name attached to a validated phone number - Identify whether a number is a mobile, landline, or special line type - Geo-locate a phone number to its associated region - Filter signup forms for unreachable phone numbers ## Use cases ### Signup Form Validation Web forms call GET /validate with the user's phone number and the apilayer access key to confirm the number is real before saving the lead. The response includes a valid flag plus carrier and line type, which downstream systems use to score the lead. Integration is a single HTTP GET. Example prompt: Call GET /validate with the submitted number and the access key, reject the signup if valid is false ### Marketing List Hygiene Marketing teams clean uploaded contact lists by passing each number through numverify and discarding entries flagged invalid or as VoIP. Cleaner lists improve SMS deliverability rates and cut spend on unreachable numbers. The single-endpoint surface makes batch processing straightforward. Example prompt: Iterate over a list of phone numbers calling GET /validate for each, retain only those where line_type is mobile and valid is true ### Agent-Driven Lead Quality Scoring An AI agent triages inbound leads by validating phone numbers through numverify and writing the carrier, country, and line type back to the CRM. Through Jentic the agent searches for 'validate phone number', loads the GET /validate schema, and executes without learning apilayer's auth conventions. Example prompt: Search Jentic for 'validate a phone number', load the schema for GET /validate, and execute for each new lead with the apilayer access key ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /validate | Validate a phone number | ## Key resources - **Validation** — Validate a phone number and return carrier, country, and line type ## Why Jentic - **Setup:** Wiring numverify by hand means passing your access_key on every query string against apilayer.net/api and handling the request plumbing yourself. Through Jentic you install once, import numverify from the API Directory, store the access key once, and your agent calls it. - **Permission scoping:** numverify exposes a single validation path with no resource id, so scope the agent to the operations it needs: allow phone-number validation and carrier lookup and nothing more. You choose the operations it may call, so it only reaches the endpoints you list. - **Credential handling:** Your numverify access key is stored once, encrypted, by your own Jentic One instance and injected as the access_key query parameter at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'validate a phone number' or 'check phone carrier', and Jentic returns the numverify operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **NumLookupAPI** — Standalone phone-validation API independent of apilayer - **Twilio Lookup** — Twilio's phone intelligence API with deeper signals like SIM swap - **Abstract API** — Multi-purpose validation suite across phones, emails, and IP addresses ## FAQ ### Why is there no official OpenAPI spec for numverify API? numverify does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call numverify API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the numverify API use? The spec declares an apiKey scheme passed as a query parameter named access_key. Through Jentic the access key is stored encrypted in the vault and appended at execution time, so it never appears in the agent's prompt or logs. ### Can numverify tell me whether a number is a landline or VoIP? Yes. The response from GET /validate includes a line_type field that distinguishes mobile, landline, VoIP, and other categories. Use it to filter out non-mobile numbers before sending SMS. ### How do I validate a phone number through Jentic? Search Jentic for 'validate a phone number', load the schema for GET /validate, and execute with the number you want to check. Jentic injects the access key from the vault and returns the parsed validation payload. ### What are the rate limits for the numverify API? Rate limits are not declared in the OpenAPI spec. numverify operates on apilayer's plan-based monthly request limits; check your apilayer dashboard for the exact quota tied to your access key. ### Is numverify free to use? numverify offers a free apilayer tier for low-volume validation and paid tiers for higher request volumes. The free tier is sufficient for most signup-form workflows but caps monthly requests; check apilayer pricing for details. ### Can I limit what my agent is allowed to do with the numverify API? Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials your agent may use. numverify exposes a single validation path (GET /validate) with no resource id, so you can allow just phone-number validation and carrier lookup and nothing else. Your agent only reaches the operations you list, and the access key stays in your instance and is injected at execution time rather than exposed to the agent.