canonical: https://jentic.com/apis/numlookupapi.com/numlookupapi # NumLookupAPI Jentic publishes the only available OpenAPI specification for NumLookupAPI, keeping it validated and agent-ready. NumLookupAPI is a phone-number validation and enrichment service that returns carrier, line type, country, and location data for numbers across 230+ countries. The API exposes a single validation endpoint plus a status check, designed for low-latency lookups at form submission or during contact enrichment. It is used by lead-quality teams, KYC pipelines, and SMS senders that need to filter invalid or expensive routes before sending. ## For AI agents Validate and enrich a phone number with carrier, line type, and country information from 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 a phone number and return its carrier and line type - Identify the country of origin for an international phone number - Filter form submissions for invalid or non-mobile phone numbers - Detect VoIP and landline numbers before sending SMS - Confirm the API is healthy via the status endpoint - Enrich CRM contact records with validated phone metadata ## Use cases ### Form Validation at Lead Capture Marketing forms call GET /v1/validate/{phone_number} when a user submits a phone number to confirm it is real and reachable. Invalid or VoIP entries are flagged before the lead lands in the CRM, reducing wasted SDR time and SMS spend. Integration is a single GET call with the API key. Example prompt: Call GET /v1/validate/{phone_number} for the submitted number and reject the lead if valid is false ### SMS Routing Optimisation SMS senders look up line type before queuing a campaign so VoIP and landline numbers do not consume mobile-only routes. The carrier and line-type fields returned by /v1/validate let the sender route or skip messages and save on per-message charges. Example prompt: Call GET /v1/validate/{phone_number} for each recipient and filter out line types other than mobile before sending SMS ### Agent-Driven Contact Enrichment An AI agent enriching new CRM contacts validates each phone number through Jentic before saving. The agent searches for 'validate phone number', loads the GET /v1/validate/{phone_number} schema, and writes the carrier and country back to the contact record. Example prompt: Search Jentic for 'validate a phone number', load the schema for GET /v1/validate/{phone_number}, and execute for each new lead ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /v1/validate/{phone_number} | Validate and enrich a phone number | | GET | /v1/status | Check API status | ## Key resources - **Validation** — Validate phone numbers and return carrier, country, and line type - **Status** — Check API service health ## Why Jentic - **Setup:** Wiring the NumLookupAPI by hand means appending your key as the apikey query parameter on every call to api.numlookupapi.com and mapping the validation and status operations yourself. Through Jentic you install once, import NumLookupAPI from the API Directory, store the API key once, and your agent calls it. - **Permission scoping:** This API puts the phone number in the URL path (/v1/validate/{phone_number}), so a rule can pin your agent to the validation operation. Both endpoints here are read-only, so you choose whether the agent validates numbers, checks status, or both. - **Credential handling:** Your NumLookupAPI key is stored once, encrypted, by your own Jentic One instance and injected as the apikey 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 'detect a VoIP line', and Jentic returns the matching NumLookupAPI operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **numverify** — Sister phone-validation API with similar carrier and line-type output - **Abstract API** — Multi-purpose validation suite covering phones, emails, and IP - **Twilio Lookup** — Twilio's phone intelligence API with carrier, line type, and SIM swap signals ## FAQ ### Why is there no official OpenAPI spec for NumLookupAPI? NumLookupAPI does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call NumLookupAPI 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 NumLookupAPI use? The spec declares an apiKey scheme. Through Jentic the API key is stored encrypted in the vault and injected at execution, so the agent never holds the raw key in its prompt or logs. ### Can I detect whether a number is a mobile or VoIP line? Yes. The response from GET /v1/validate/{phone_number} includes the line type field, which lets you distinguish mobile, landline, and VoIP numbers before routing SMS or making a call. ### How do I validate a phone number through Jentic? Search Jentic for 'validate a phone number', load the schema for GET /v1/validate/{phone_number}, and execute with the number you want to check. Jentic returns the parsed validation payload with carrier and country. ### What are the rate limits for NumLookupAPI? Rate limits are not declared in the OpenAPI spec. NumLookupAPI applies plan-based monthly request limits in production; check your dashboard for the quota that applies to your key and tier. ### How do I check that the NumLookupAPI service is healthy? Call GET /v1/status to confirm the service is responsive. Use this in scheduled health checks or as a cheap pre-flight before running a high-volume validation batch. ### Can I limit what my agent is allowed to do with the NumLookupAPI? Yes. Because you run Jentic One yourself, your own rules decide which NumLookupAPI operations the agent may call and which credential it uses. Both operations here are read-only, so you can allow the agent to run only the phone validation call at GET /v1/validate/{phone_number}, only the GET /v1/status health check, or both. Since the phone number sits in the URL path, you can pin the agent to validation and enrichment without exposing anything beyond those two endpoints.