> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Line type and reachability classification model > The three classification surfaces Orbit exposes — the free public checker, the billed per-lookup endpoint, and the sender-identity-type resolver — how to read a line-type verdict per channel, what a 'depends' answer means under a BYO-carrier model, and how to wire classification into quiet-hours, RND, and opt-out posture. # Line type and reachability classification model A line type tells you what a number *can* do, not whether a message to it was delivered. This page is the model for reading that signal: which of Orbit's three classification surfaces answers your question, what the per-channel reachability verdict actually means, and where an operator wires classification into tenant-owned posture — quiet-hours windows, the Reassigned Numbers Database (RND) scrub, and opt-out lists. For the dip-level fields of the billed lookup, see the [Number Lookup model](/concepts/number-lookup-model). ## The three classification surfaces Orbit classifies numbers and sender identities on three surfaces, in order from cheapest to most authoritative: | Surface | What it answers | Cost | | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------- | | Public checker (`/tools/carrier-lookup`) | Structural line type from the numbering plan — mobile, fixed line, toll-free, VoIP, premium rate, shared cost, pager, UAN, personal number, voicemail | Free, unauthenticated | | Billed Lookup endpoint (`GET /numbers/lookup/{phone}`, `POST /numbers/lookup`) | Live network answer — current carrier, portability, tri-state `lineStatus` (active / inactive / unknown), plus opt-in packages like SIM swap and caller name | Billed per answered dip | | Sender-identity-type resolver | Which class of sender a `from` identity is — long code, toll-free, short code, or alphanumeric sender ID | Computed, free | Use the public checker in pre-purchase flows and triage — an anonymous visitor can validate and classify a number without consuming lookup credits. Behind it sits the same structural [E.164 validator](/quickstart) the platform's format helpers use, so the checker never disagrees with the API about whether the input is a complete, dialable number. Run the billed Lookup when you need a live network answer (list hygiene at import time, pre-screens before high-risk sends, the Numbers → Lookup console desk-check flow). The sender-identity-type resolver runs whenever you list senders — the compliance surfaces render "Long code" / "Toll-free" / "Short code" / "Alphanumeric sender ID" instead of lumping every `from` identity under "Number". ### How classification feeds tenant posture Sender-identity classification is what makes the compliance profile's pre-send evaluation readable: in the Messaging Compliance Health panel each sender row rests under its true identity class, so a screened quarantine on one class (e.g. unverified alphanumeric) can be read without mislabeling phone numbers as non-numeric senders. The send gate evaluation itself — quiet hours, DNC, RND, preference checks — is documented under [Send Gates](/compliance/send-gates); the identity resolver ensures the sender shown in those gate decisions is labeled correctly. Ownership stays with the tenant: except for the sole platform-global federal TCPA dialing window, every posture check is a tenant-configured control. Billed lookups feed list hygiene. A typical flow: run a bulk Lookup on newly imported numbers, filter for `lineStatus` !== `active` or a fixed line / premium rate / shared cost type, and route the misses into your [opt-out list](/guides/opt-out-lists) or a suppression import before a campaign touches them. The checker is the free first-pass of that same triage; the Lookup is the authoritative second pass you pay per dip. ## Reading the reachability verdict The public checker resolves a line type from the numbering plan and maps it to a general reachability verdict per channel: | Line type | SMS | Voice | Note | | -------------------- | ------- | ----- | ---------------------------------------------------------------------- | | Mobile | yes | yes | Mobile numbers generally accept both SMS and voice traffic. | | Fixed line or mobile | depends | yes | The range serves both; SMS support depends on which it actually is. | | Fixed line | no | yes | Landlines don't receive SMS unless the carrier offers text-enablement. | | Toll-free | depends | yes | SMS-enablement sticks only after toll-free SMS verification. | | VoIP | depends | yes | Provider-dependent; treat as uncertain without a direct test. | | Premium rate | no | yes | Voice/billing lines, not standard SMS endpoints. | | Shared cost | no | yes | Voice lines, not standard SMS endpoints. | | Pager | depends | no | Legacy messaging-only category. | | UAN | no | yes | Universal Access Numbers route voice; no SMS. | | Personal number | depends | yes | Follow-me services vary in SMS support by provider. | | Voicemail | no | no | Voicemail-access range, not a reachable subscriber line. | An incomplete input or an invalid number resolves `depends` on both channels with a note that says why it couldn't classify. Per channel, the verdict stacks like this: * **SMS** — a `yes` means the numbering category supports A2P/P2P SMS; a `depends` means the category supports SMS for some provisioned instances (fixed-or-mobile ranges, toll-free after verification, VoIP with a provider add-on); a `no` means the category is not an SMS endpoint. * **Voice** — nearly every reachable numbering category terminates a call; `no` is reserved for pager and voicemail-access ranges. * **RCS and WhatsApp** — neither gets a separate verdict. Both inherit the SMS constraint: you need an SMS-capable destination before the richer channel can even attempt a capability fall-back. WhatsApp registration materially narrows to mobile lines, and RCS delivery mirrors SMS's reachability — treat a fixed-line-type `no` for SMS as a matched `no` for RCS/WhatsApp, and upgrade a `depends` only after a SMS test confirms the line. Where WhatsApp adds no business-voice fallback, see the [WhatsApp Business Calling model](/concepts/whatsapp-business-calling-model). ## When a lookup answers "depends" A `depends` verdict is not a shrug — it is the honest answer for a category where the provisioned instance, not the numbering plan, decides reachability. In a BYO-carrier agreement the classification still holds (the number's plan-derived type doesn't change when you attach carrier credentials), but who provisions SMS on a VoIP or fixed-or-mobile range does change. The [BYO carrier lifecycle](/concepts/byo-carrier-lifecycle) page covers how attaching your own SMPP carrier shifts reachability from market-average empirics to your own bind's capability. Operators should treat BYO ranges classified `depends` as candidates for a binding-capability test message rather than as excluded destinations. The billed Lookup narrows `depends` further: HLR returns the current serving carrier and the tri-state `lineStatus`, so a tentative checker verdict resolves to a live one at send-decision time. Where `depends` stays unresolved — especially on VoIP — the safe posture is tenant-owned suppression (move the number off your send lists until a test message or the subscriber's own choice settles it), not an optimistic send. ## Cross-links and downstream surfaces * [Compliance country requirements](/compliance/country-requirements) — sender-ID restrictions that vary by country. The line-type verdict does not override these: an SMS-`yes` mobile number still hits the country's sender-class rules before a send dispatches. * [Send Gates](/compliance/send-gates) — the quiet-hours / DNC / RND / preference evaluations that run at send time; line-type signals choose which channels are worth attempting, the gates choose whether a send runs. * [BYO carrier lifecycle](/concepts/byo-carrier-lifecycle) — how attaching your own carrier changes what a `depends` verdict means. * [Number Lookup model](/concepts/number-lookup-model) — the dip catalog behind the billed endpoint and how its cache trades freshness against cost. * [Number Intelligence dashboard](/guides/number-intelligence-dashboard) — the console, metering, and daily-cap surfaces for operator-side lookups. * [Opt-out lists](/guides/opt-out-lists) — where filtered-out numbers land when classification says "not an SMS endpoint".