Overview

Simnet runs a separate compute platform per region, and a resource exists in exactly one of them. So every request has to be routed, and the X-Region-Context header is how you choose.
The value is a region UUID, from GET /api/v1/onboarding/regions/activated.
There is no cross-region lookup. Asking region A for a resource that lives in region B returns Not found, not a redirect — and a 404 here means “not in this region”, which is easy to misread as “deleted”.When you store a resource identifier, store its region alongside. You will need both to act on it later.

Omitting the header

The header is optional. Without it the API picks a region for you:
Send the header explicitly in anything automated. The implicit path depends on which region happens to come back first, which can change as accounts are added — a script that worked for months can start acting on a different region without any change on your side.

When a region account isn’t usable

A region is only usable when your account in it is ACTIVE with a provisioned identity, and the region itself is ACTIVE with a reachable endpoint. If either half fails, the region is skipped on the implicit path and refused on the explicit one.
All three come back as 403 Access denied, including the malformed-UUID case — which is a client error and would more naturally be a 400. Don’t build retry logic that treats 403 as “permanently forbidden”: here it frequently means “fix the header” or “activate a region”.

Activating a region

Regions are opt-in per account. The relevant endpoints are under Account:
Activation is asynchronous — it provisions an account on that region’s platform. A region can appear in the activated list before it is fully usable, so a 403 immediately after activating usually means “not ready yet” rather than “failed”. Retry after a few seconds.

Zones are not regions

A region contains zones, and the two are specified differently.
A zoneId is only meaningful within the region the request routed to. Pairing a zone from one region with a header naming another produces a 422 from the platform, and the detail is not always obvious about the cause.Fetch zones with the same region header you intend to use for the create.

Worked example: deploy into a specific region

1

List your activated regions

2

Pin the region for every subsequent call

3

List zones in that region

4

Deploy, sending the same header

Set the header once in your HTTP client’s defaults rather than per call. Doing it per call is how one request in twenty ends up on the wrong region.

Region groups

An X-Multi-Region-Context header exists, naming a group of regions so a list call fans out across all of them and returns a combined result with a regionErrors entry for any that failed.
This is off by default. A request carrying the header is refused with
If both headers are present, X-Region-Context wins and the group is ignored. Don’t build on this until it is enabled for your account.

Regions and zones

The concepts, in the console guides.

Errors

Why these come back as 403.

Authentication

Identity, and organization context.

Conventions

Pagination and response envelopes.