Skip to main content
Use regional configuration to record the intended Twilio region and edge for a deployment review. Saving these fields does not move a running service or establish where every system processes data. Twilio Regions and Edge Locations serve different purposes. Region-specific credentials differ from the default region’s credentials; an edge selects an entry or exit location. See Twilio’s regional usage documentation.

​
Accepted configuration

The current Threetone region_config requires region_id, token, and edge_location when supplied. These enums are an input contract. They do not certify every combination or automatically accept regions added by the provider.

​
Review a regional route

1

Identify the region owner

Confirm the account, number, and intended regional resources with your Twilio administrator. Avoid combining a regional endpoint with credentials from another region.
2

Match the accepted fields

Compare the proposed values with Import phone number. Keep enable_sms false and omit account_auth_token as required by the Twilio import guide.
3

Review runtime delivery

Document how the future runtime will receive the regional credentials and choose its endpoints. Import redacts credential metadata; saving the regional token does not demonstrate usable secret delivery.
4

Plan regional acceptance checks

When the runtime is supported, verify the selected route in provider records and measure signaling and media separately. Keep a known fallback and document how it will be restored.
For an authentication failure, verify the account and regional credential pair before changing network routes. For latency, inspect the complete caller-to-runtime path rather than assuming the nearest edge resolves every delay.

​
Frequently asked questions

Only the current schema’s region values are accepted. Provider support can be broader than the Threetone request contract.
No. Review the actual provider, application, model, logging, and storage paths and the applicable agreements separately.