Skip to main content
telli stores phone numbers in E.164, the international standard format: a +, the country code, and the subscriber number, with no spaces, punctuation, or national dialing prefix - for example +4915112345678 or +14155552671. Numbers that pass validation are normalized to this form and returned that way in API responses, webhook payloads, and exports. You don’t have to submit numbers in exact E.164, though. Every path that brings contacts into telli - the contact API, CSV import, and the CRM integrations - runs numbers through the same normalization and validation, then stores the E.164 result.

​
Accepted input formats

Using a German mobile number as an example, these inputs all normalize to +491751234567: After normalization, telli checks that the country code is recognized and that the number has a possible length for that country, and rejects anything else. It does not check whether the number is actually allocated in that country’s numbering plan.

​
Why national formats are rejected

A number like 01751234567 is ambiguous: without a country code, telli can’t tell whether it’s a German, Austrian, or other number. Guessing a default country would silently turn some numbers into valid-looking but wrong international numbers - and calls would reach the wrong person. That’s why numbers must carry explicit country context. Convert national numbers to E.164 on your side before sending them. For German numbers that’s a simple transformation: replace the leading 0 with +49 (01751234567 → +491751234567). The rule differs by country - Italian numbers keep their leading zero after +39, for example - so for anything beyond a single known country, use a library instead of a hand-rolled rule.
If you integrate in code, use a libphonenumber port for your language to parse and format numbers to E.164 - ports exist for JavaScript, Python, Java, PHP, and most other ecosystems.

​
Where this applies

The same normalization and validation runs on the main paths where phone numbers enter telli: Numbers accepted on these paths are stored - and later returned in webhook payloads, API responses, and exports - as the normalized E.164 number.

​
Fields that require strict E.164

An agent’s transfer number skips the lenient normalization and only accepts a number that already starts with +, digits only - no spaces or punctuation. The 00 prefix and bare country-code forms are rejected there.