Landline Carrier Lookup: Reading Fixed-Line Number Results

A practical guide to interpreting original carrier and allocation information for landline numbers.

A landline carrier lookup can provide context about the number range to which a fixed-line number was originally allocated. CarrierLookup's realtime Original Carrier Lookup may return an original carrier, underlying carrier, number type, country code, and allocation region or city when those values are available. These fields describe numbering context, not the current serving provider or the location of a person or device. Start with a correctly formatted international number, read any returned fields as source-specific facts, and leave empty fields as unavailable. For a large, essentially one-country list, a separate asynchronous file task can return a CSV for review.

What a landline carrier lookup is asking

The word landline is often used for fixed-line or geographic telephone numbers, but numbering categories vary by country. A national regulator's plan is the appropriate starting point for a country-specific claim. For example, the UK regulator Ofcom explains that its 01 and 02 codes identify geographic number areas; it also warns that those area codes do not locate a mobile phone. This example illustrates why a generic international rule such as 'all landlines begin with one prefix' would be unreliable.

CarrierLookup answers a narrower, operational question: what original allocation context is available for a particular number? Its Original Carrier Lookup is synchronous for one number and supports a multi-number route. The returned number type can help a team distinguish a fixed-line classification from a mobile classification when provided. Carrier and underlying-carrier fields describe the original range allocation, not a live connection. A result is not a call test, a subscriber directory, or a way to determine whether the line is presently in service.

Start a review by writing the decision that needs the lookup. A CRM team may want to separate contact records by returned number type. A routing team may want original carrier context as one input to later tests. Those purposes require different follow-up evidence. Recording the exact question prevents the carrier result from becoming an unsupported claim about delivery or customer identity.

Prepare a fixed-line number for the realtime route

The documented realtime input is E.164 format: a leading plus sign, country code, and subscriber number without spaces or separators. Do not assume a domestic dial string can be submitted unchanged. National trunk prefixes and area-code conventions differ, so a country-specific normalization rule should be checked against the relevant numbering plan before it changes the source record. Keep the original string as received and the normalized candidate in separate fields. This makes an accidental deletion or duplicated country code visible during review.

POST /api/v1/check is the documented single-number route. The synchronous POST /api/v1/batch-check route accepts a group of numbers and preserves input order. The dashboard also has a realtime multi-number workflow. These are checks returned in the request flow; they are distinct from a bulk file task that completes later. Use the CarrierLookup API documentation for the current request contract and integration details. An API key belongs on a trusted server, not in browser code or a published example.

A rejected input format is not a finding that no carrier exists. Correct or quarantine malformed numbers before comparing results. For a mixed-country realtime review, the documented multi route can accept international numbers from different countries. That does not mean a file task follows the same rules: the file route selects one country. Choosing the route before exporting prevents a mixed-country file from being mislabeled.

Read number type, carrier, and geography separately

Read the returned number type first, then the original carrier fields, then the allocation geography. The number type tells the team how the result classified the number in this context. The carrier field names the carrier to which the range was originally allocated. The underlying-carrier field may add separate network-allocation context. Empty optional fields mean a usable value was not returned for that field; they should remain empty rather than being replaced with a made-up operator or city. A completed lookup can still have empty carrier fields.

The region and city fields, when present, refer to number-range allocation geography. They are not a person's residence, a device's live location, or proof that a fixed line is physically installed in that city today. Ofcom's numbering data shows how a regulator can publish range allocation information; that does not transform an allocation label into a location tracker. The country code similarly describes numbering context and should not be presented as a person's nationality.

Portability matters even for a landline discussion. Ofcom describes rules allowing customers to keep a landline number when changing provider. The original carrier field can therefore differ from the provider serving the number now. The product does not publish a current-carrier field. When an operational decision requires the current provider, the team needs evidence from an appropriate separate process rather than relabeling the original allocation result.

Separate landlines from mobiles in a mixed list

A mixed CRM export often contains local-format numbers, international numbers, duplicates, and records with no clear type. Build a working list before checking. Normalize each candidate using a country-specific rule, preserve the raw value, and flag ambiguous rows for manual review. Run a small realtime review when the team is inspecting new records or needs a synchronous result. On import, join the result back to the normalized input and keep the returned number type in its own field. Do not use a prefix table as the final classification for records with a returned product value.

For a large list that is essentially one selected country, the separate Global carrier lookup accepts a one-column TXT or CSV with one country-coded number per line. It runs asynchronously. The documented API routes are POST /api/v1/bulk-tasks for submission and GET /api/v1/bulk-tasks/{id} for status; query no more often than every 30 seconds. A successful task yields one CSV, with the carrier and allocation fields documented for that product. Current acceptance conditions are in the product and API documentation. Do not send a workbook or infer that the bulk route accepts a mixed-country file just because the realtime route does.

After download, group rows by returned number type only when that field has a usable value. Keep unavailable values in their own group. Review apparent fixed-line rows separately from mobile rows before any operational routing tests. That grouping can inform which team or workflow should inspect a record, but it does not guarantee that a call or message will reach the subscriber.

Turn the result into a careful review action

A useful contact record stores the original input, normalized number, lookup product, lookup date, returned number type, original carrier, and any allocation geography as separate fields. These are suggested internal recordkeeping choices, not a promise that every field will be populated. The team can create a review queue for records whose type conflicts with the source database, whose carrier fields are empty, or whose normalization needs correction. Avoid interpreting every blank as an invalid number; a normal completed lookup may have unavailable optional fields.

Before using the result for routing or outreach, confirm the other facts those tasks require. CarrierLookup does not establish reachability, consent, subscriber identity, or current location. A compliance or permission decision belongs to the organization's own records and applicable process. With those boundaries understood, the lookup can support a cleaner division of fixed-line and mobile contact records and a more transparent explanation of what the data actually shows.

FAQ

Can teams find the current landline provider from this lookup?

The carrier field describes the carrier to which the number range was originally allocated. A number may have been ported, so this is not a current-provider result. Keep the value labeled as original carrier and use a separate, appropriate source if the operational question requires the present serving provider.

Does a returned city show where a landline user is now?

No. The city and region fields describe allocation geography for the number range when available. They are not a live location or a person's address. If the field is empty, retain it as unavailable. If a team needs an address for a permitted business process, it should use an independently collected address record.

Should a landline with empty carrier fields be marked invalid?

No. A completed lookup can have empty optional carrier fields. Preserve the completed status and the empty values separately. A rejected format or an undetermined lookup follows a different review path. The team should correct malformed inputs and investigate unresolved checks rather than turn every missing carrier value into an invalid-number verdict.

Learn More

Choose the product information that fits the next step in your workflow.

• View the product documentation →
• Talk to the team →