Region pinning
A sable_region pin is a refusal mechanism, not a router. A Sable
deployment declares which region it runs in; a pin matching that declaration is
honored and recorded on the signed receipt, and any other pin is rejected with
400. Nothing is ever quietly served from a region you didn't ask for.
But a deployment can only honor its own region, and one that declares no region
can't honor a pin at all.
What a pin actually does
The operator declares where the gateway runs via SABLE_GATEWAY_REGION, which
is validated at boot. That declaration (not the caller's preference) is
what the gateway stamps on the receipt. A pin is compared against it:
sable_region | Deployment declares | Outcome |
|---|---|---|
| omitted | eu-central | Runs. Receipt region: "eu-central". |
| omitted | nothing | Runs. Receipt region: "unspecified". |
eu | eu-central | Runs. Receipt region: "eu-central". |
us-east | eu-central | 400: this deployment serves eu-central. |
eu | nothing | 400: pinning unavailable on this deployment. |
atlantis | anything | 400: unknown region. |
Unpinned requests are unaffected by any of this.
Where this deployment runs
GET /v1/nodes answers it. The entry with id gateway carries the declared
region, or the literal string unspecified when the operator declared none,
in which case every pin is refused.
curl -s https://api.buildsable.com/v1/nodes
[
{
"id": "gateway",
"name": "Sable gateway",
"region": "eu-west",
"tee_kind": null,
"privacy_tier": "standard",
"status": "online",
"synthetic": true
}
]
synthetic: true means the entry is derived from this deployment's
configuration rather than from a separately enrolled machine; enrolled fleet
nodes appear alongside it with synthetic: false. The gateway entry is the
one that answers the region question.
Pinning a request
/v1/chat/completions, /v1/embeddings, and /v1/messages accept an optional
sable_region body field. Pass a broad alias (eu, us, ap) or a canonical
code (eu-central, eu-west, us-east, us-west, ap-southeast). The region
names hosting providers use (fra, iad, oregon, singapore and friends)
resolve to the same canonical codes, so fra and eu both mean eu-central.
The examples below pin to eu-west, the region the production gateway
declares. Against a deployment that declares anything else, they return 400;
check /v1/nodes for the deployment you call.
resp = client.chat.completions.create(
model="sable-deepseek-v3",
messages=[{"role":"user","content":"Summarize this filing"}],
# Honored only if this deployment declares eu-west; otherwise 400.
extra_body={"sable_region": "eu-west"},
)No silent fallback
A pin the deployment can't honor fails with 400. It is never softened to
the nearest region and never quietly routed elsewhere: the refusal is the whole
guarantee.
{
"error": {
"message": "bad request: this deployment serves region 'eu-central', not 'us-east'",
"type": "bad_request"
}
}
If the operator declared no region at all, the gateway cannot honor any pin, and says so instead of accepting one it can't back:
{
"error": {
"message": "bad request: region pinning is unavailable on this deployment, so 'eu-central' cannot be guaranteed (the operator has not declared SABLE_GATEWAY_REGION)",
"type": "bad_request"
}
}
A region string we don't recognize is a 400 as well: a typo is refused,
never ignored.
Confirming where it ran
The serving region comes back two ways:
x-sable-regionresponse header- the
regionfield inside the signed receipt
Both carry the deployment's declared region, or unspecified when it
declared none. Because region sits inside the signed payload, it is
tamper-evident: the same secp256k1 signature that proves the request ran also
covers where it says it ran, so the value can't be changed after the fact
without breaking verification. Be precise about what that buys you: the
signature attests the operator's declaration, not an independent
measurement of where the hardware sits.
One region per deployment
Sable runs as a single gateway deployment today, so there is exactly one region
it can honor. A pin to any other region is a refusal: correct, and deliberately
not a route. Multi-region routing is not live. Serving several jurisdictions
at once takes capacity in each, which arrives with the fleet (not yet built).
Until then, read sable_region as an assertion you want checked, not a
destination you can choose.
That check is the enforcement half of the sovereign tier's
jurisdiction promise, the half that refuses.