Countries & requirements
Porting rules are national. The platform routes each order to the right provider per country and attaches that country's legal requirements automatically. This page summarizes what's supported today; the requirements API is always the source of truth:
# by number — we classify it and answer for its route:
curl "https://api.example.com/v2/porting/requirements?phone_number=%2B14155552671" \
-H "Authorization: Bearer pk_live_YOUR_KEY"
# or by route:
curl "https://api.example.com/v2/porting/requirements?country_code=US&number_type=mobile" \
-H "Authorization: Bearer pk_live_YOUR_KEY"
(The full catalog of every requirement type the platform knows — across all
countries — is at GET /v2/porting/requirement_types.)
On every order, regardless of country
The end-user identity fields are requirements like any other, attached to every order:
| Requirement | Type | Mandatory |
|---|---|---|
Authorized person (auth_person_name) |
text | yes |
Service address (location) |
address | yes |
Company name (entity_name) |
text | no |
Billing phone number (billing_phone_number) |
text | no |
These are the platform defaults — the requirements preview and the
requirements array on your orders are always the authoritative checklist,
so build against those rather than this table.
United States (US)
Handled by our mobile carrier partner. In addition to the universal fields:
| Requirement | Type | Notes |
|---|---|---|
Letter of Authorization (loa) |
signature | US wording (mobile carrier + Number Transfer PIN). Show the localized LOA text from the requirements preview, collect a drawn-signature PNG — the platform generates the signed document |
Account number (account_number) |
text | Must match the losing carrier's CSR exactly |
Transfer PIN (port_out_pin) |
text | Mobile numbers only; 4–10 digits, issued by the losing carrier ("Number Transfer PIN") |
Recent invoice (recent_invoice) |
document | Optional but speeds up exception handling |
Timing: mobile ports are often same-day once the PIN and account data are correct. Wrong account number / PIN are the dominant rejection causes.
United Kingdom (GB)
Handled via Telnyx. In addition to the universal fields:
| Requirement | Type | Notes |
|---|---|---|
Letter of Authorization (loa) |
signature | Ofcom-compliant UK wording. Show the localized LOA text from the requirements preview, collect a drawn-signature PNG — the platform generates the signed document |
Account number (account_number) |
text | The account number with the losing carrier — the GB LOA prints it, so it must be filled before signing |
Recent invoice (recent_invoice) |
document | Must be under 30 days old |
Address proof (uk_postcode_proof) |
document | Local (geographic) numbers only — utility bill or invoice showing the installation address, under 90 days |
Timing: UK mobile ports typically complete in a few business days; local numbers can take longer depending on the losing communications provider.
Notes that apply everywhere
- Numbers must pass a portability check before ordering.
- Requirements differ not just by country but by number type (mobile vs local vs toll-free) — always query the requirements preview.
- Some ranges route to unexpected countries: e.g.
+44 7911 …is Guernsey (GG), not GB. The portability check tells you what we detected. - A country without an active routing rule is refused with a clear
422— contact us if you need a new destination; adding one is configuration, not code. - LOA wording is per country — and localized. The requirements preview
(
GET /v2/porting/requirements?country_code=…) carries the LOA text in every available language (en,es,fr,de,aron the built-in templates) plus thedisclosuresthe signer must accept — your UI only displays it and collects a drawn signature. Ops can add or override templates (including translations) without a deploy viaPOST /admin/loa_templates.