What a region determines
A region determines where HTTP data is received or executed and stored. The selected region applies to the request's HTTP data, not necessarily to all account information. Selecting a region does not promise separate placement of all account data.
Inbound: Server region
Choose an available region when creating a Server. Its region and public address cannot change afterward. Direct executes in the region that received the request; CLI delivers from the computer running the client, so the local recipient URL must be reachable from that computer.
To use another region, create another Server, configure Channels and Routers, and change the sender's URL. The old URL does not automatically start receiving requests elsewhere. This operation does not automatically migrate previously accepted requests.
Outbound: job region
Call GET /outbound/regions with an API token at https://api.adal.cloud. Select a returned id and send it as region_id when submitting a request. Do not derive an identifier from a country or city name.
An independent submission does not need an incoming Server. Each new submission can select its own region; changing a later form or application selection does not relocate an accepted job.
Catalog and availability
Use the current environment's region catalog rather than a static documentation table. A listed region does not guarantee immediate execution or recipient availability. The dashboard shows the name, country and city where available.
If a region is temporarily unavailable, HTTP data may be unreadable while the journal record remains visible. Check the environment and retry reading later. Do not resubmit an Outbound job with a new key merely because reading its result failed.
Related rules
Selecting a region does not change retention or the shared traffic balance. Follow idempotency rules when submission results are uncertain. Start with a Server or API submission.