Twilio error 13223 is thrown when the phone number inside a Dial verb's Number noun does not conform to a valid phone number format that Twilio can route. Unlike the callerId validation (13214), which checks account ownership, 13223 is a pure format validation failure on the destination number. This error fires before any carrier routing attempt and is always fixable by correcting the number format in your TwiML.
What Causes This Error
The primary cause is providing a phone number without the E.164 international format, which requires a leading plus sign followed by the country code and subscriber number with no spaces, dashes, or parentheses: for example, a US number must be written as +12125551234, not (212) 555-1234, 1-212-555-1234, or 2125551234. A second cause is dynamically generating the Dial Number content from a database or user input field that stores numbers in a local format without country codes, where the concatenation logic does not prepend the correct country code for each number. Passing a SIP URI in a Number noun instead of a Client or Sip noun is a structural TwiML mistake that also produces 13223, since the Number noun expects a telephone number string, not a sip: URI. Numbers with an incorrect digit count for their country code, such as a US number with 9 or 12 digits instead of 11 (country code plus 10-digit subscriber number), will also fail this format check.
How to Fix It Step by Step
Retrieve the raw TwiML that triggered the error from the Twilio Debugger under Monitor, then Debugger and inspect the Number noun content to see exactly what value was passed. Normalize the value to E.164 by stripping all non-digit characters (spaces, parentheses, dashes, dots) and prepending the correct country code and a plus sign: for US numbers add +1 before the 10-digit number, for UK numbers add +44 and remove the leading 0 from the area code. If you are generating TwiML dynamically, implement a normalization function using libphonenumber-js that calls parsePhoneNumber(rawNumber, 'US') and then formats the result with format('E.164'), which handles country code insertion and formatting for all countries. Re-test your TwiML by pasting the corrected document into Twilio's TwiML Validator tool in the Console to confirm the Number noun parses as valid before re-deploying.
How to Prevent It from Recurring
Store all phone numbers in your database exclusively in E.164 format, enforced by a column constraint that rejects any string not matching the pattern ^+[1-9]d{1,14}$, so that malformed numbers can never enter the data layer that feeds your TwiML generation. Apply E.164 normalization at every system boundary where phone numbers are ingested: user input forms, CRM data imports, API integrations, and CSV uploads should all pass numbers through a normalization function before storage. Add a unit test to your TwiML generation function that asserts the Number noun content in the generated TwiML matches the E.164 regex for every destination country your application dials. If you use the Twilio official helper library to generate TwiML, pass phone numbers through the library's DialNoun rather than building the XML manually, as the library performs format validation on the number before serializing it into the TwiML document.
When to Call a Specialist
If your numbers look correctly formatted in E.164 but 13223 errors persist, check for invisible Unicode characters embedded in the number string, such as a non-breaking space or a right-to-left mark inserted by a CRM or document editor, which makes the number appear correct visually but fail Twilio's format validation. A specialist can run a byte-level inspection of the number strings flowing through your system to identify any hidden characters that are corrupting the format. You should also seek specialist help if you are dialing SIP URIs and want to combine them with phone number Dial in the same TwiML response, as the correct TwiML structure requires separate noun types (Number for PSTN numbers, Sip for SIP URIs, Client for browser clients) and mixing them incorrectly produces format errors.
Conclusion
Error 13223 is a Dial Number format issue that is fixed by normalizing all destination phone numbers to E.164 format in your TwiML generation logic before returning the response. If this error is blocking your production system, contact our team and we will diagnose and fix it within the hour.
Ready to Transform Your Business Communications?
Get a free consultation with our VoIP experts and discover how we can help you save costs, improve efficiency, and scale your business.
Comments (0)
Join the discussion and share your thoughts (AI-moderated for quality)
Be the first to comment
No comments yet. Share your thoughts below.