Integrations

Add numbers.online as a caller-name (CNAM) source in FreePBX’s CID Superfecta module. On each inbound call Superfecta asks numbers.online for the caller’s name and — if you opt in — flags higher-risk callers using a low-confidence, supplementary spam signal at a threshold you choose. It is a single drop-in PHP file configured entirely from the FreePBX admin UI; your PBX keeps every routing, labeling, and blocking decision.

1. Drop source-NumbersOnline.module into Superfecta’s sources/ directory and run fwconsole chown.
2. In Admin → CID Superfecta, enable the NumbersOnline source in your inbound route’s scheme and order it above your fallbacks.
3. Paste your API key into the source’s API_Key field; optionally set the spam flag and threshold. It fails open — a slow or failing lookup never delays the call.

Label an inbound call with a caller name and an optional risk tag before it reaches an extension. The simplest path points FreeSWITCH’s mod_cidlookup at the plain-text /v1/cid endpoint (it pastes the response body verbatim as the caller name). For routing on the risk score, header auth, and verified TLS, the included Lua dialplan script calls the JSON /v1/lookup endpoint instead. Risk wording is opt-in — you choose the tag text and threshold.

1. mod_cidlookup: copy cidlookup.conf.xml to conf/autoload_configs/, set your key in the ?key= URL param and your default country, then reload mod_cidlookup.
2. Lua (optional, fuller): copy numbers_online_cnam.lua to conf/scripts/, set numbers_online_key in vars.xml (never hardcoded), and call it early in the inbound route.
3. Multi-tenant FusionPBX: mint a per-tenant sub-key through the MSP control plane so usage and billing are attributed per domain.

Add numbers.online as a server-side CRM source so 3CX resolves unknown inbound callers to a business name, tenant-wide, with no client-side software. When a call arrives from a number that is not already a 3CX contact, 3CX requests a caller name (CNAM) and shows it on a hit. Known 3CX contacts always win, and a number with no available name simply shows as the raw number — nothing is invented.

1. In the 3CX Admin Console, go to Settings → CRM → Server side and upload numbers-online.crm.xml.
2. Paste your API key into the numbers.online API Key field and save.
3. Restart the 3CX System Service (required), then use the built-in CRM Test with a +E.164 number to verify.

Show a caller’s name, line type, and a low-confidence risk signal as a Windows toast the moment an inbound call rings your MicroSIP softphone. MicroSIP runs a command on each incoming call; a PowerShell script normalizes the number, calls the lookup API, and pops a desktop notification. This is a desktop demo of the lookup signal — for production call flows the integration point is your PBX/SBC. An operator-chosen risk label is prefixed only above a threshold you set.

1. Save NumbersOnlineLookup.ps1 and numbers-online-lookup.bat to C:\tools\numbers-online\.
2. Set your key as the NUMBERS_ONLINE_API_KEY user environment variable (the script reads it from there — never stored in the file).
3. Point microsip.ini’s cmdIncomingCall at the .bat wrapper and restart MicroSIP. It fails open and logs nothing.

Give an AI voice agent — Vapi, Retell, Pipecat, LiveKit — read-only phone intelligence over the Model Context Protocol. A single Streamable HTTP endpoint exposes five tools (phone_lookup, line_type, caller_risk, dnc_check, reassigned_check) the model can call before it burns agent minutes: who is this caller, and is this number one I should think twice about dialing. dnc_check and reassigned_check are preview tools that return “unknown” (and are unbilled) until a licensed data partner is configured. Every answer is a supplementary, low-confidence signal with an optional signed receipt — the agent keeps the routing and dialing decision.

1. Mint an API key with the “mcp” use case (any lookup-entitled key already has it).
2. In Vapi, add an MCP tool pointing at https://numbers.online/api/v1/mcp with metadata.protocol "shttp" and an Authorization: Bearer header (sample below).
3. Vapi auto-discovers the tools via tools/list. It fails open and stays well under the 7.5s assistant-request budget; a slow lookup degrades to a neutral signal, never a dropped call.

Resolve an inbound caller for a Retell agent before it answers. Point Retell’s call_inbound webhook at numbers.online and it injects dynamic variables — caller name, line type, a low-confidence risk signal, and DNC / reassigned status — into the agent prompt as {{caller_risk}}, {{caller_on_dnc}}, and friends, plus a signed receipt id. The webhook always returns 200 within Retell’s 10s budget (fail-open), so a slow or failing lookup never keeps the caller ringing.

1. Set your agent’s inbound webhook URL to /api/v1/integrations/retell/inbound?key=YOUR_API_KEY (use a dedicated, rotatable key).
2. Reference the injected variables in your agent prompt — they are labeled supplementary signals, not verdicts.
3. Verify with a test inbound call; the response includes a receipt_id you can retrieve later as TCPA-defense evidence.

Prefer a Vapi custom function tool over the MCP server? Add a phone_lookup function whose server URL is numbers.online; Vapi calls it mid-conversation and the agent gets back the same supplementary intelligence bundle (validity, line type, carrier, caller name where available, spam signal, DNC / reassigned status) as a JSON string, with a signed receipt id. Fail-open: a bad argument or supplier hiccup returns a graceful message the agent can speak around.

1. Add the custom function tool to your assistant, server URL https://numbers.online/api/v1/integrations/vapi/tool with an Authorization: Bearer header (sample below).
2. Use a key with the “mcp” use case; each call meters the bundled per-call rate.
3. For full MCP tool discovery instead, use the “AI voice agents (MCP)” card above — both share one lookup backend.

Turn a Kamailio instance into a ClearIP-compatible SIP redirect server in front of your SBC. On an inbound INVITE the included config asks numbers.online for a low-confidence decision on the calling number and maps it to a SIP reply — 603 to decline, 302 to divert to a screening target you configure, or a 503/404 route-advance to allow. It fails open within a tight call-setup budget: a slow or failing lookup advances the call unchanged. Your route logic — not numbers.online — keeps every decision; a 603 only ever follows a deterministic or government/licensed-authoritative fact.

1. Load http_async_client + jansson and include numbers_online_sbc.cfg in kamailio.cfg.
2. Put your API key in a Kamailio define/AVP (never hardcoded in the committed cfg); the recipe reads it from there and sets a sub-second $http_req(timeout).
3. Call the route early on INVITE; map decision=block→sl_send_reply("603"), decision=redirect→302 to your screening Contact, else route-advance. It fails open on timeout/error.

Call numbers.online from an OpenSIPS routing script via rest_client when an inbound INVITE arrives, then act on the supplementary decision — relay, divert with a 3xx, or decline with 603 — before the call reaches a trunk or extension. The signal is advisory and coverage is partial; treat any uncertainty as allow. Note the rest_client timeout is second-granular, so the OpenSIPS path’s worst case is ~1s rather than sub-500ms — size your call-setup budget accordingly. OpenSIPS keeps every routing and blocking decision.

1. Enable the rest_client + json modules and include numbers_online_sbc.cfg in opensips.cfg.
2. Store your API key in a script var/AVP loaded from the environment — never commit it.
3. Invoke the lookup route on INVITE and branch on the JSON decision; it fails open so a timeout relays the call.

Run the Kamailio redirect recipe under dSIPRouter so inbound calls across your endpoint groups get a supplementary numbers.online signal. Multi-tenant deployments mint a per-tenant sub-key through the MSP control plane so usage and billing roll up per customer. Advisory only — your routing rules keep every decision. (A packaged dSIPRouter/dOpenSource add-on listing is a distribution step, not required to use the recipe.)

1. Apply the Kamailio numbers_online_sbc.cfg to your dSIPRouter-managed Kamailio config and reload.
2. Per tenant, mint a sub-key via the MSP control plane and set it in that tenant’s config so usage rolls up per customer.
3. Branch on the decision in your inbound route; it fails open on the call-setup path.