twilio-21210TwiliolowPhone Number Already Verified
The phone number is already registered as a verified caller ID on this Twilio account.
What this error means
Root causes
Automated provisioning script runs multiple times without checking existing verified numbers
Common
Account setup webhook or onboarding flow does not guard against duplicate verification attempts
Common
Retry logic after a previous partial failure re-attempts verification for a number that completed successfully
Occasional
Multiple services or workers concurrently attempting to verify the same number in a race condition
Occasional
Manual verification was done in the Twilio Console prior to running an automated setup process
Rare
How to fix it
- 1
Check existing verified caller IDs before attempting verification
Before initiating the caller ID verification flow, query the Twilio API to see if the number is already in your verified caller ID list. If it is, skip the verification step entirely.
const twilio = require('twilio'); const client = twilio(process.env.TWILIO_ACCOUNT_SID, process.env.TWILIO_AUTH_TOKEN); async function ensureVerifiedCallerId(phoneNumber) { // List existing verified caller IDs const existing = await client.outgoingCallerIds.list({ phoneNumber }); if (existing.length > 0) { console.log(`${phoneNumber} is already a verified caller ID — skipping verification.`); return existing[0]; } // Initiate verification only if not already verified const validation = await client.validationRequests.create({ phoneNumber, friendlyName: 'My Caller ID' }); return validation; } - 2
Treat 21210 as a non-fatal informational response
Update your error handling code to catch 21210 specifically and treat it as a success case — the number is already verified and ready to use. Only throw or log a warning for this code rather than treating it as a hard failure.
async function addVerifiedCallerId(phoneNumber) { try { await client.validationRequests.create({ phoneNumber }); console.log(`Verification initiated for ${phoneNumber}`); } catch (err) { if (err.code === 21210) { // Already verified — this is fine console.info(`${phoneNumber} already verified, continuing.`); return; } // Re-throw unexpected errors throw err; } } - 3
List all verified caller IDs in the Twilio Console
Navigate to Phone Numbers > Verified Caller IDs in the Twilio Console to see all numbers currently verified on your account. This is useful for auditing which numbers are already set up and for manually removing stale entries that are no longer needed.
- 4
Implement idempotent provisioning logic
Design your provisioning scripts to be idempotent — running them multiple times should produce the same result without errors. Use a 'check before create' pattern for all Twilio resources including verified caller IDs, phone numbers, and TwiML apps.
- 5
Add deduplication to concurrent verification workflows
If multiple workers might verify the same number simultaneously, use a distributed lock (Redis SETNX, database row lock, etc.) to ensure only one process attempts verification for a given number at a time. Release the lock once verification completes or after a timeout.
const redis = require('redis'); const client = redis.createClient(); async function verifyWithLock(phoneNumber) { const lockKey = `verify_lock:${phoneNumber}`; const acquired = await client.set(lockKey, '1', { NX: true, EX: 60 }); if (!acquired) { console.info(`Verification for ${phoneNumber} already in progress — skipping.`); return; } try { await ensureVerifiedCallerId(phoneNumber); } finally { await client.del(lockKey); } } - 6
Remove outdated or stale verified caller IDs
Periodically audit your verified caller ID list and remove numbers that are no longer in use. This keeps your account clean and reduces the chance of confusion in provisioning workflows. Use the Twilio REST API to list and delete caller IDs programmatically.
Prevention
Prevent 21210 errors by designing all provisioning and setup workflows with idempotency in mind. Before attempting to add any resource to Twilio, query the API to check if it already exists. Implement a 'check-then-create' pattern with proper error handling that treats 21210 as a no-op success. Use distributed locking if multiple services may attempt to provision the same resource concurrently. Log all provisioning actions with enough context to reconstruct the sequence of events if an unexpected 21210 occurs, making it easy to diagnose retry or race condition issues.
Debugging this right now?
Sherlock diagnoses twilio-21210 automatically. Just ask in Slack and get an instant root-cause analysis.
Add to Slack — Free