Regions + data residency
Today
- One host:
api.wholisphere.ai(dashboard:app.wholisphere.ai). Use it regardless of where your org is based. - Processing: requests execute on Cloudflare’s network (Workers run at the edge closest to the caller).
- Storage: a single primary datastore (Cloudflare D1, plus KV / R2 / Durable Objects) — not region-pinned.
- Third parties: LLM providers (Gemini, Claude), Stripe, and Resend are global services; we send them only the data each call needs (page content you submit, billing identifiers, email metadata).
The region field you may see on an org (e.g. in GET /v1/auth/me) is recorded for future use; it defaults to us and does not change where data is stored today.
Planned: region-scoped deployments
Region-scoped deployments — so captures, audit events, and embeddings stay inside the right border for EU GDPR, APAC localization, or US-only contracts — are on the roadmap. No dates are committed. The design below is planned, not live.
Planned hosts
| Region | Host | Status |
|---|---|---|
| US (default) | api.wholisphere.ai | live (serves all orgs today) |
| EU | eu.api.wholisphere.ai | planned |
| APAC | apac.api.wholisphere.ai | planned |
Dashboard hosts would mirror the same prefixes (e.g. eu.app.wholisphere.ai).
Planned behavior
- Pinning: org owners would pick a region in Settings → Organization → Region; all org data would then live in that region, with cross-region migration as a support-assisted operation.
- Misdirected requests: a request authenticated as an org pinned to region X arriving in region Y would get HTTP 421 Misdirected Request with
x-wholisphere-correct-regionandx-wholisphere-correct-hostheaders, and the SDK would auto-retry against the correct host.
Don’t build 421 handling into custom integrations yet — nothing returns it today. Watch the changelog for when this ships.