Separate the public number from the extension
Store +12025550123 as the canonical public number and 456 as a separate extension. Do not append the extension to E.164, apply country numbering rules to it or include it in an SMS destination.
A practical form can offer one phone field and one optional extension field. If pasted input contains markers such as ext, extension or x, parse them conservatively and show the result before saving.
Represent extensions in tel URIs
RFC 3966 uses the ext parameter: tel:+12025550123;ext=456. The extension parameter identifies a station behind a PBX and remains distinct from the global phone number. Read the normative RFC 3966 specification for parameter syntax and comparison rules.
A tel URI identifies a telephone resource; it does not guarantee that every device will automatically send extension digits after a call connects. Test the behavior on the platforms your users actually use.
Model extension rules locally
Extensions belong to an organization's private routing plan, so there is no universal global length. Define permitted characters and length from your own PBX or product requirements. If only digits are supported, say so in the field hint and reject other characters without changing the public number.
Database and API shape
{
"phoneE164": "+12025550123",
"extension": "456",
"verifiedAt": null
}Keep verification state separate as well. Verifying the public number does not necessarily prove access to every extension, and an extension can change without the public line changing.
Extension test checklist
- Missing extension remains valid when optional.
- Leading zeros are preserved when the PBX treats them as significant.
- Overlong input produces a specific extension error.
- SMS and OTP integrations receive only the public E.164 value.
- Display formatting and tel links include the extension only where supported.
See the broader phone-number database guide for storage and uniqueness decisions.