Regions

Floopy runs in more than one geographic region so requests are answered close to your users. The endpoint you call decides which region serves the request — the data your account stores never leaves Europe.

All three endpoints accept the same OpenAI-compatible requests, return the same response shapes, and respect the same API keys. Pointing your client at any of them is a one-line change to your baseURL.

When you call https://api.floopy.ai, the routing layer looks at the request’s network origin and forwards it to the region closest to you in terms of network distance. If a region is unhealthy, requests automatically fail over to the other one — no change on your side.

This selection happens per request. Calls from a single client can in principle hit different regions over time (for example, if your client moves networks or if a region is briefly unavailable). For deterministic targeting use one of the pinned endpoints above.

Your account data — request logs, traces, organizations, projects, API keys, billing — is stored only in our European data store regardless of which endpoint served the request. The Brazilian region holds only short-lived per-request state needed to answer the call.

This means:

• A request served by api-br.floopy.ai is logged into the same European data store as one served by api-eu.floopy.ai. The two regions share dashboards, audit trails, billing aggregates, and exports.
• The data store’s compliance and retention guarantees apply uniformly. Switching regions does not move historical data anywhere new.
• The region that served each request is recorded on the log row, so you can filter analytics by region after the fact.

Each region maintains its own response and embedding caches. The first request for a given input in a region you haven’t used recently can be slightly slower than a cached hit — the answer is the same, only the timing differs. After the cache warms up, subsequent calls within the same region see the usual cache speedups.

If you switch a workload between api-eu.floopy.ai and api-br.floopy.ai, expect a similar warm-up period on the new region.

• api.floopy.ai — Pick this by default. It minimizes latency without locking you to a region.
• api-eu.floopy.ai / api-br.floopy.ai — Pick a pinned endpoint when:
  • You’re benchmarking latency from a specific origin.
  • You need a stable target for an incident-response runbook.
  • You’re A/B-testing regional behavior or measuring cache warm-up effects.

If the closest region becomes unhealthy, api.floopy.ai routes new requests to the other region automatically. Existing in-flight requests are not migrated — they either complete or return an error from the original region. Once the affected region is healthy again, traffic rebalances on its own.

Pinned endpoints (api-eu.floopy.ai and api-br.floopy.ai) do not fail over. If you point a client at a pinned endpoint and that region becomes unhealthy, those requests fail until the region recovers. Use api.floopy.ai if you want automatic failover.