Skip to content

Developer guide

How routing works

CloudSitus is one endpoint in front of many providers. Two headers — X-Region and X-PHI — decide which host serves a request, and the response tells you exactly what happened.

The decision

Every request is resolved in four steps.

You never call a provider directly. You describe the request; the router resolves an ordered list of routes that satisfy your region and data class, then uses the best one.

1 · Pick the region

The X-Region header chooses which providers may serve the request. In CH, the EU and the US the router sends it to that region’s data-resident provider first; the other regions are served by global clouds, which process globally. It never routes to a provider that does not serve the region you named.

2 · Declare the data class

X-PHI: true restricts routing to providers whose data-processing agreement is verified for that jurisdiction. If none exists for the region + modality, the request is refused (403) rather than crossing a border.

3 · Choose a model (or auto)

model: "auto" (or "flash") lets the router pick the cheapest eligible model; "think" picks the cheapest measured reasoning model and "pro" the fastest measured one — all resolved per request for your region and data class, so they never go stale. Or pin a concrete id, or a provider-agnostic canonical alias that resolves per region. A pin is honoured or refused, never swapped for another model.

4 · Failover, in-tier

On an upstream error the router walks an ordered candidate list. PHI requests only ever see PHI-eligible routes, so a failover can never spill to an unverified host — and never leaves the region.

Region residency

Each region has its own route.

For auto traffic the router prefers the region’s data-resident provider (CH, EU and US) and, within it, the cheapest eligible model; other clouds serving the region rank behind it. The other named regions are served by Google, which processes globally. WORLD has no resident provider, so it is pure price order. A pinned model still wins if it serves the region.

RegionAnswers chatPHI chat
CHInfomaniakEligible
EUScalewayEligible
USTogether AIGeneral
UK · ASIA · ANZ · INDIA · LATAM · MENAGoogleGeneral
WORLDOpenAIGeneral

Computed by the router from the model catalogue when this page was built; defaults follow price and move as the catalogue does — GET /v1/models is always current. CHINA has no host and returns 422 no_route.

PHI for the document & voice modalities (OCR, speech-to-text, text-to-speech) is additionally served by Microsoft Azure in CH, EU and US under a HIPAA BAA + regional DPA. See /vendors for the full registry.

Modality coverage

What’s available where.

Coverage differs per modality, and each one is residency-separate (no cross-border failover). A region with no host for a modality returns 422 no_route — by design.

ModalityRegionsPHI
Chat completionsEvery region except CHINACH, EU
EmbeddingsCH, EUCH, EU
VisionEvery region except CHINACH, EU
OCRCH, EU, USCH, EU, US
Speech-to-textCH, EU, US, WORLDCH, EU, US
Text-to-speechEvery region except CHINACH, EU, US

In the hosted chat these surface as the paperclip (image → vision, PDF → OCR, audio → transcription), the mic (voice input), and the “Listen” button (text-to-speech) — each enabled only when your pinned region supports it.

Canonical aliases

One name, any region.

Instead of a concrete model id you can pass a provider-agnostic alias. Combined with X-Region it resolves to whichever provider hosts that model in your region — so the same code runs everywhere.

  • gemma-4

    CH → Infomaniak (PHI-eligible) · EU → Scaleway (PHI-eligible)

  • qwen3.5

    CH → Infomaniak (PHI-eligible) · EU → Scaleway (PHI-eligible)

  • kimi-k2.6

    CH → Infomaniak (PHI-eligible)

  • qwen3-embedding-8b

    CH → Infomaniak (PHI-eligible) · EU → Scaleway (PHI-eligible) (one 4096-d vector space everywhere)

  • whisper

    CH → Microsoft Azure (PHI-eligible) · EU → Scaleway (PHI-eligible) · US → Microsoft Azure (PHI-eligible)

Audit headers

Every response is auditable.

The routing decision is echoed back on each 200, so you can record exactly what served the request and what it cost.

response headers
x-phi-routed:   infomaniak-nemotron-nano-30b/CH/phi   # model / region / data class
x-phi-provider: infomaniak   # verified sub-processor that answered
x-phi-tier:     phi          # phi | non_phi
x-phi-attempts: 1            # routes tried before success
x-phi-usage:    verified     # verified | missing | suspect
x-phi-cost-micro: 4200       # metered cost, micro-USD
x-request-id:   9f1c…        # quote in support

x-phi-provider names the verified upstream sub-processor that answered, and x-phi-usage grades how far the billed amount can be trusted — verified (a sane upstream count), missing (none reported, billed $0), or suspect (malformed, clamped). x-phi-usage and x-phi-cost-micro are absent on streamed responses, where usage lands after the headers are sent.

A 403 phi_blocked means you asked for PHI in a region/modality with no verified host — the gateway refuses rather than crossing a border. Pin a region that has one (e.g. CH or EU).

Ready to wire it up?

One endpoint. Every region you serve.

The API reference has copy-paste cURL, Python and Node for every endpoint — including vision, OCR and audio.

Prepaid credits from $10 · No subscription · No data retained