Twilio errors · 2026

Twilio error 21217: “phone number does not appear to be valid”, and the list fix behind it

Last updated September 4, 2026

Twilio's page for 21217 is one sentence long: check the phone number and try again. That is the right advice for a developer testing one number and useless for someone who just imported 3,000 rows from a lead vendor and watched a fifth of them fail. The numbers are usually fine. The formatting is not, and the spreadsheet they passed through made it worse. Here is what Twilio wants, the eight ways a list breaks it, the one formula that fixes most of them, and how to tell the leftovers from genuinely dead numbers.

Eight ways a list produces 21217

The one-formula fix in Google Sheets

For a US or Canadian list with raw numbers in column A, put this in B2 and fill down. It strips everything that is not a digit, prepends +1 to ten-digit numbers, adds a plus to eleven-digit numbers that already start with 1, and leaves anything else blank so you can see it:

=IF(LEN(REGEXREPLACE(TO_TEXT(A2),"[^0-9]",""))=10,
   "+1"&REGEXREPLACE(TO_TEXT(A2),"[^0-9]",""),
 IF(LEN(REGEXREPLACE(TO_TEXT(A2),"[^0-9]",""))=11,
   "+"&REGEXREPLACE(TO_TEXT(A2),"[^0-9]",""),
   ""))

Before you paste, select column B and set Format → Number → Plain text, or Sheets will helpfully turn +14155552671 back into a number and drop the plus on export. Then filter B for blanks: those rows are the ones with seven digits, letters, or two numbers in one cell, and they need a person. Extensions go in their own column; Twilio will not dial “x204” and a dialer can send the digits after connect instead. For UK, Irish or Australian lists the rule changes (drop the trunk zero, add the country code); the country-by-country versions are in how to clean a lead list before you dial it.

Why the spreadsheet is the usual culprit

A CSV that passes through Excel or Sheets has its phone column read as a number. The plus disappears because it is not a digit. Past about eleven digits the cell displays scientific notation, and on export it is written out that way, or as “4155552671.0” with a trailing decimal. Twilio parses neither. The safe habit is to open the CSV with the phone column forced to text, or to never round-trip a list through a spreadsheet at all: import the vendor's file straight into the dialer.

A good importer expects this. DialSheet's normalises every number to E.164 with a default country of US or Canada, undoes the trailing-decimal and scientific-notation forms, strips punctuation, adds the country code, and reports the rows it could not parse instead of dropping them. It exists because a 60,000-row import in September 2026 arrived with 21,528 numbers in the “.0” form, every one a valid US number underneath.

Formatting failure or dead number?

1. Normalise first. Anything that cannot be normalised never reached Twilio; fix or drop it.
2. Dedupe on the normalised value. Vendors sell the same number in three formats; you do not want to dial it three times.
3. Look up what is left. Twilio Lookup's line-type intelligence costs about a cent a query and returns whether the number is assigned and whether it is mobile, landline or VoIP. Drop the unassigned ones; they are the real dead numbers and the source of the 21217s and 13224s that survive cleaning.
4. Scrub before you dial. A clean list is not a compliant list; see do you have to scrub the DNC list.

Neighbouring errors

• 13224 is the Dial-verb twin and also covers well-formed numbers Twilio cannot route (premium ranges, non-existent area codes). See Twilio call blocked errors.
• 13227 / 21215 means the number is fine and the country is switched off. See geo permissions.
• 21210 is your caller ID, not the number you dialed. See error 21210.

Questions people actually ask