This article covers everything you need to plan and complete your migration, like which countries have shutdown dates, how to tell if you're affected, which migration path fits your setup, and how to weigh the tradeoffs between them.

This HCA supports efforts to EOL Transit Caller ID.  The following information is critical to support this change. Included in the Article: 

• Affected countries are Brazil and France. 
• The comm will be sent on September 8, 2026 to customers the us Transit CID for calls to France and Brazil. 
• See the remaining HCA for workarounds and FAQs. 

Which countries are affected and when

Transit Caller ID is being retired one market at a time. If you place outbound calls to any of the countries below, complete your migration before that country's shutdown date. Calls that use an unverified non-Twilio number as the caller ID after the shutdown date will fail with error code 21212 on Programmable Voice or error code 32204 on Elastic SIP Trunking.

Beyond this list, some local carriers may already block or restrict these types of calls in Germany, Norway, and Sweden, for example. We'll add rows to this table as more countries reach end of life; however, if you call any of those markets today, migrate now rather than waiting for a formal date. 

How to know if this affects you

Two things need to be true for this to affect you:

1. You place outbound calls to a country with an active shutdown date, or to a country where carriers already restrict unverified caller IDs.
2. Some of those calls use a phone number that isn't a Twilio number as the caller ID.

To check the second one, look at your account verified caller IDs:

1. Go to Numbers & Senders > Verified Caller IDs in the new Twilio Console.
2. Review the list. Any number that appears there is a valid caller ID on your account.
3. Compare it to the caller IDs used on your outbound calls to affected countries.

Any caller ID you use that isn't in that list and isn't a Twilio number on your account will be impacted by this shutdown. If you're not sure how your account uses non-Twilio numbers, check your call logs for the From value on outbound calls to affected countries and compare that against your Twilio number inventory.

Choose your migration path

Once you've identified affected traffic, pick the path that matches how you use non-Twilio numbers. Some accounts run both patterns; if that's you, follow both paths.

Not sure which pattern applies? Ask yourself: is the number I'm displaying as the caller ID the number of the person who originally called me (forwarding), or a number I bought from another provider and use to originate calls myself (multi-sourcing)?

Call forwarding

Call forwarding is when an inbound call arrives at your voice application or contact center and you pass it back out to the public telephone network, so the person you're forwarding to sees who's really calling. Twilio continues to support this pattern; what changes is the mechanism by which the original caller's number is preserved on the outbound leg.

Your migration steps depend on the product you're using.

Elastic SIP Trunking

Use Immutable Call Forwarding. It preserves the original caller's number on the forwarded call without relying on Transit Caller ID. "Immutable" means the original caller ID can't be changed on the outbound leg, which is exactly what carriers need to see for the call to be trusted, and why it's the supported forwarding pattern going forward.

The mechanism is header-based. On the inbound call, Twilio adds an X-Twilio-CallToken header to the SIP INVITE. On the outbound leg, your PBX or SBC needs to return that same header unchanged, with From set to the original caller's number. In practice, most PBXs and SBCs modify or strip custom headers by default, so you'll likely need to configure header manipulation rules to preserve X-Twilio-CallToken end-to-end. Test in a lower environment before cutting production over; a silently stripped header looks fine locally and fails the moment you go live.

Immutable Call Forwarding is available to all Elastic SIP Trunking accounts, but it's off by default. Open a ticket with Support to have it turned on.

Already using Transit Caller ID for forwarding on ESIPT? Twilio is migrating your account automatically. Your forwarded calls will keep working in the meantime, and we'll contact you once the migration is complete. Two things to know: you don't need to open a Support ticket to get on the list, and we still recommend adopting the header-based configuration above for the long term, since it's the supported setup going forward and doesn't rely on any transitional behavior.

Programmable Voice with TwiML <Dial>

This is the smallest change of any migration path: remove the callerId attribute from your <Dial> verb. Passing the inbound caller's number through is the default behavior once that attribute is gone, so Twilio handles the rest with no extra configuration.

If you have multiple TwiML documents that forward calls, remove callerId from each one. Read the TwiML <Dial> documentation for details.

Programmable Voice with the REST API

Use CallTokens. A CallToken is a signed token Twilio generates on every incoming call, and passing it through on the outbound leg tells carriers the original caller ID came from the public telephone network, which is the piece they need to trust it.

Compared to the TwiML change, this is real engineering work. The migration itself is three steps:

1. Configure a webhook to receive the CallToken on the inbound call leg.
2. Store the token temporarily per call, not long-term.
3. Pass the token back, along with the original caller's number in the From parameter, when you create the outbound Call or Conference Participant via the API.

The complexity is proportional to your app's architecture. If your inbound and outbound legs live in the same process, this is straightforward; read the token from the inbound webhook payload, hold it in memory, and pass it when you fire the outbound request. If they're separated across services, queues, or workers, you'll need to carry the CallToken through your handoff layer, and that's where most of the integration work usually lands. Start with your highest-volume forwarding path first so you get the biggest coverage from the earliest work.

See Use a CallToken when forwarding a call for the full walkthrough with code samples.

Multi-sourcing: your two options

Multi-sourcing is when you've built a phone number inventory with another provider and want Twilio to handle the outbound calling on those numbers. To keep those calls connecting after your country's shutdown date, you have two paths forward:

1. Verify each non-Twilio number with Twilio using Verified Caller ID.
2. Move your numbers onto your Twilio account either by buying new Twilio numbers or porting the ones you already have.

Either works everywhere except Brazil, where Verified Caller IDs aren't accepted and moving to Twilio is your only option. Outside Brazil, the right choice depends on how many numbers you have, how much ongoing management you want, and how much the specific numbers matter to your recipients.

Here's how the two paths compare:

You don't have to pick one path for your whole inventory. Many accounts do a mix; verify the numbers they want to keep on non-Twilio infrastructure, and move Brazil traffic (or long-term consolidation candidates) onto Twilio.

Verifying with Verified Caller ID

Verified Caller ID is a one-time OTP flow. In the Twilio Console, go to Numbers & Senders > Verified Caller IDs, select Add a new Caller ID, enter the number, and complete verification with the passcode you receive by SMS or voice call. Once verified, that number keeps working as a caller ID from that account or subaccount indefinitely, you won't need to re-verify unless you deliberately remove it.

A few things worth knowing before you start:

• Some countries block caller ID verification by SMS. If SMS verification fails, switch to voice verification, both the API and Console support it.
• Verified Caller IDs are per-account. A number verified on one subaccount isn't automatically valid on another. Verify on each account or subaccount that needs to use the number.
• Use the API for large inventories. The Outgoing Caller IDs REST API is far faster than clicking through the Console once you have more than a handful of numbers. Sample code is in the Verifying caller IDs at scale guide.
• If OTP won't work at all, for example, you can't reach the receiving line to enter the passcode, contact your Twilio account team. There's a Letter of Authorization process for accounts that can't complete standard verification.

Moving your numbers to Twilio

If verification isn't a fit (for example, because you call Brazil, because you'd rather not manage two providers, or because you're already planning to consolidate) you have two ways to get numbers onto your Twilio account.

Buying new Twilio numbers is immediate. Search and buy in the Console or use the Available Phone Numbers API. Once purchased, the numbers work as caller IDs on your account with no verification step. The tradeoff is that recipients see new numbers, which can affect answer rates if they recognized your existing ones. Worth thinking about for outbound flows where the number is part of the brand.

Porting keeps the numbers you already have, but takes weeks. Timelines depend on your losing carrier's response times and the country the number is registered in. Start a porting request with the Number Porting team as soon as you can if porting is your path. The porting window doesn't shrink because your shutdown date is close. If you call Brazil and want to keep your existing numbers, this is the one to start on as soon as possible.

Many customers use a mix: port the numbers that are recognized and valuable, buy new ones where recognition doesn't matter as much.

Test your migration before your shutdown date

Once you've migrated, confirm your calls behave the way you expect before your country's shutdown date. Waiting until after the date means fixing under pressure with calls already failing.

• Place a test call to a number in each affected country you serve, and confirm the caller ID displays correctly on the receiving end.
• Watch your call logs for error code 21212 on Programmable Voice or error code 32204 on Elastic SIP Trunking on affected traffic. Either error indicates the caller ID isn't being accepted.
• If you moved to CallTokens, confirm the token is received on the inbound leg, stored, and passed back on the outbound leg for every forwarded call.
• If you moved to Verified Caller ID, confirm every number you use as a caller ID appears in Numbers & Senders > Verified Caller IDs for the account or subaccount making the call.
• If you're on Elastic SIP Trunking with Immutable Call Forwarding, confirm the X-Twilio-CallToken header is being returned unchanged by your PBX or SBC on the outbound INVITE. Most misconfigurations show up here.

If you see errors before your shutdown date

Some countries transition to the new rules in stages. Ahead of a country's shutdown date, you may see intermittent failures on affected traffic, the same errors you would see after the shutdown (error code 21212 on Programmable Voice or error code 32204 on Elastic SIP Trunking on affected traffic), just not on every call.

Intermittent failures during the transition give you a way to identify unverified traffic in your production logs while there's still time to migrate it, rather than discovering the problem after the full shutdown. Treat any intermittent failure on affected-country traffic as a signal, not noise. The number of failed calls will only grow between the start of the transition and the shutdown date.

If you see these errors on calls to an affected country, at least one of your caller IDs isn't verified. Use the steps in How to know if this affects you above to identify which numbers need attention.

Getting help

• Your Twilio account team. For porting, new number acquisition, or if you can't find a migration path that works for your setup, contact your account team.
• Twilio Support. Open a ticket if you need Immutable Call Forwarding turned on for your Elastic SIP Trunking account, or if you're seeing unexpected errors after migrating.

Frequently asked questions

Can I keep using Transit Caller ID after my country's shutdown date? 

No. Calls to a country past its shutdown date that use an unverified non-Twilio number as the caller ID will fail. There are no extensions.

What workaround options exist for customers?

Immutable Call Forwarding, Call Tokens, Verified Caller IDs, Purchasing or Porting numbers to Twilio are all options.   See these reference  docs. 

• Use a CallToken when forwarding in a call
• How to add and remove a Verified Phone Number or Caller ID with Twilio
• Verifying caller IDs at scale
• Using a non-Twilio number as the caller ID for outgoing calls
• How to Port a Phone Number to Twilio Help Center Article
• Buy a Twilio phone number

Do I need to verify Twilio Owned numbers? 

No. Numbers you bought from Twilio are already valid caller IDs on the account where you bought them.

My country isn't listed with a shutdown date. Do I need to act? 

Transit Caller ID is being retired in every market over time, and we'll give you notice before each group. Some carriers already block or restrict calls that display unverified numbers regardless of Twilio's timeline. If you call any of those markets, migrate now rather than waiting for a formal date.

I call Brazil with numbers from another carrier. What are my options? 

Brazilian carriers don't accept Verified Caller IDs on non-Twilio numbers, so the fix is to use a number on your Twilio account as the caller ID. Buy new Twilio numbers or port your existing numbers to Twilio. Get in touch with your account team and we'll help you plan it.

I call both Brazil and other countries. Do I need two setups? 

No. A Twilio number works as the caller ID everywhere, so moving your Brazil traffic onto Twilio numbers also covers the rest. You only need Verified Caller IDs for non-Twilio numbers you plan to keep using in countries outside Brazil.

How long does verification take? 

Verification is completed as soon as you enter the one-time passcode you receive. Plan for a few minutes per number in the Console, or use the Outgoing Caller IDs REST API for bulk work.

Does a Verified Caller ID work across all my accounts? 

No. A Verified Caller ID is valid only on the account or subaccount where you verified it. Verify the number on each account that needs it.

Does this require code changes, or is it a configuration change? 

It depends on the path:

• TwiML <Dial>: Small application change; remove one attribute.
• REST API with CallTokens: Real engineering work. You'll receive, store, and replay a token across two call legs.
• Elastic SIP Trunking with Immutable Call Forwarding: Configuration change on your PBX or SBC. Some setups need header manipulation rules added.
• Verified Caller ID: No code change at all.

I already verify caller IDs with my own systems. Do I still need to verify them with Twilio? 

Yes. Twilio's verification is separate from any upstream checks you or your provider run. Regardless of your existing controls, you'll need a Verified Caller ID on the Twilio account or subaccount making the call.

Which error codes will I see if a call fails?  

• error code 21212 on Programmable Voice 
• error code 32204 on Elastic SIP Trunking.