Issue
This article addresses an issue encountered by resellers and customers who create or operate custom front-end interfaces, often integrated with third-party platforms, to enable their clients to purchase, re-route, and configure phone numbers via their interface. While clients are successfully able to buy numbers and re-route them to other regions, they are currently unable to configure webhooks or update phone number properties through the interface. This article provides guidance and troubleshooting steps to resolve this limitation and ensure full functionality of number configuration capabilities.
Product
REST API and TwiML
Cause
Third-party integrations typically utilize Twilio APIs on the backend to handle number purchases, re-routing, and configuration. While purchasing and initial re-routing work successfully using the default Twilio base URL, once a number is re-routed to a specific region such as AU1 or IE the API base URL must be updated to the corresponding regional endpoint (AU1 or IE).
Additionally, these regional API calls require regional authentication tokens to properly validate credentials. Failure to update the base URL and use the correct regional auth tokens prevents successful configuration of webhooks and phone number properties.
Resolution
Step 1: Purchase the Number
Customers can purchase a number through the third-party interface using the default Twilio API base URL. This works seamlessly as the number initially belongs to the US1 region.
Step 2: Re-route the Number
- If the number is re-routed to US1, no changes are needed; customers can continue to operate using the default base URL.
- If the number is re-routed to AU1 or IE1, the re-routing action itself can still be performed using the default base URL since the number starts in US1 by default.
Step 3: After Re-routing to AU1 Region
- Once the number is re-routed to AU1, all subsequent operations such as configuring voice settings or webhooks must use the regional API base URL.
- The authentication credentials must also be regional. While the Account SID remains the same, the auth token must be the one issued for the AU1 region.
Step 4: After Re-routing to IE1 Region
- Once the number is re-routed to IE1, all subsequent API operations must use the regional API base URL.
- Similarly, the auth token must be from the IE1 region, although the Account SID remains unchanged.
Step 5: Summary
For all configuration or operational API calls on a re-routed number, the API base URL and authentication credentials must correspond to the number’s current route region. Using the correct regional endpoint and matching auth token ensures successful configuration of webhooks and phone number properties.