Issue

If you are updating your Twilio phone number’s VoiceUrl or VoiceFallbackUrl via the REST API and notice that inbound calls continue to use an old webhook, or your API changes are not reflected in live call routing, you may be encountering a regional configuration mismatch. This article explains why this happens, how Twilio’s regional infrastructure works, and how to ensure your configuration changes take effect as expected.

Symptoms

• VoiceUrl/VoiceFallbackUrl changes via REST API do not affect live calls.
• Twilio Console changes take effect immediately, but REST API changes do not.
• Calls and Monitor/Alerts APIs appear stale or do not show recent activity.
• Webhook signature validation fails with your current Auth Token.
• No error is returned by the API (HTTP 200), but live behavior does not match configuration.

Product

Programmable Voice

 

Environment

Twilio Console

Cause

Twilio’s Programmable Voice is a regionalized platform. Each phone number is “homed” in a specific region (e.g., US1, AU1), and Voice configuration is per-region. REST API endpoints and credentials are also region-specific.

Common causes for this issue:

• Using a deprecated or incorrect API endpoint (e.g., api.au1.twilio.com) that actually routes requests to US1, not AU1.
• Updating configuration via the REST API in US1 for a number homed in AU1 (or vice versa).
• Using an Auth Token or API Key from the wrong region.
• Assuming Console and API changes are always equivalent—when in fact, the Console is region-aware and the API may not be.

Resolution

How to Diagnose

1. Check the API Endpoint:
   • Deprecated endpoints like api.au1.twilio.com process all requests in US1, regardless of the region code.
   • The correct format is {product}.{edge}.{region}.twilio.com (e.g., api.sydney.au1.twilio.com).
2. Check Number Home Region:
   • Numbers purchased in the Console with a specific region selected are homed in that region.
   • Numbers provisioned via the API without specifying a region default to US1.
3. Check Credentials:
   • Auth Tokens and API Keys are only valid for the region in which they were created.
   • For webhook signature validation, use the Auth Token from the region where the number is homed.
4. Check API Responses:
   • If you see X-Home-Region: us1 in the response headers when you expect AU1, your request is being served by US1.

How to Fix

1. Use the Correct Regional Endpoint:
   • For AU1: api.sydney.au1.twilio.com
   • For US1: api.twilio.com
   • Always include the edge label (e.g., sydney for AU1).
2. Create and Use Region-Specific Credentials:
   • In the Console, select the correct region (e.g., AU1) and create an API Key or obtain the Auth Token for that region.
   • Use these credentials for all API requests and webhook signature validation.
3. Pin Numbers to the Correct Region (API):

   • When provisioning numbers via API, explicitly set the region:

     POST https://routes.sydney.au1.twilio.com/v2/PhoneNumbers/%2B61XXXXXXXXX
     -d VoiceRegion=au1

   • Then configure Voice URLs in AU1.
4. Verify Configuration:
   • After making changes, place a test call and confirm the correct webhook is invoked.
   • Use the Console to check the live configuration and region.

Additional Information

• Failover Configuration:
  • If configured in the correct region, failover (VoiceFallbackUrl) works as expected.
• Calls API:
  • Each region maintains its own call records. Query the correct region for recent activity.
• Deprecated Endpoints:
  • Endpoints like api.au1.twilio.com are deprecated and may return HTTP 200 with stale data from US1. Always use the documented, region-aware endpoints.

Below you will find references to useful documents:

• Using the Twilio REST API in a Non-US Region
• How to Route a Twilio Phone Number to AU1 or IE1 Region
• Deprecation of Region-Specific Twilio API Domain Patterns

Example Scenario

A customer updated the VoiceUrl for an AU1-homed number using api.au1.twilio.com and saw HTTP 200 responses, but inbound calls continued to use the old webhook. Console changes worked immediately. The root cause was using a deprecated endpoint that routed requests to US1, not AU1. Switching to api.sydney.au1.twilio.com and using an AU1 API Key resolved the issue.

Summary Table

If you have further questions or need help updating your integration, please refer to the documentation above or reach out to Twilio Support.