Provider Requirements

1. Why this matters

The inference provider is the party that runs the model on your data. The same model is often offered by several providers in different countries and on different terms. We assess every endpoint before admission and enforce the result on every request.

We assess each endpoint, meaning a specific provider, model and region. We do not approve a provider as a whole. A provider's headquarters is never used as a substitute for where inference actually runs.

2. Admission requirements

No training

The provider's published terms or agreement state that API inputs and outputs are not used to train or improve models.

Zero data retention

Prompts and outputs are not stored after the request is completed. Only transient caching strictly necessary for inference is accepted.

Processing location

The region where the endpoint runs inference is documented. Endpoints are only admitted to a region's route when that location is established.

Legal basis

The provider has a published data processing agreement and terms that permit our use, including reselling through our service where applicable.

Security posture

We record the provider's certifications (such as ISO 27001 and SOC 2) and those of its infrastructure partners, and its published security practices.

Breach notification

The provider commits to notify customers of personal data breaches, so that we can meet our own 72-hour commitment.

Qualification testing

Before production use, we test the endpoint for correct output, streaming, tool calls, long context, error handling, latency and billing accuracy.

Every requirement is backed by a dated source, such as a policy page, DPA or written confirmation from the provider. These sources are kept in our provider register.

3. How the result is enforced

Region routes

Only admitted endpoints appear in the approved route for each region. A request under a region rule can only reach those endpoints.

Provider allow-list

Your administrator decides which admitted providers may serve your workspace. A newly admitted provider never joins your list automatically.

Every attempt counts

The rules apply to the routing classifier, the answer request and every retry or fallback. A fallback cannot reach a provider that your policy excludes.

Fail closed

If no compliant endpoint is available, the request fails with a clear error. It is never sent to a non-compliant endpoint instead.

4. Ongoing review

Policy sources are re-checked regularly and whenever a provider announces changes to its terms, DPA or sub-processors.

Prices, availability and error rates are monitored continuously. Endpoints that fail quality checks are removed from routing.

If an endpoint stops meeting a requirement, it is removed from the affected region routes immediately. We inform affected customers where this changes their sub-processors.

Adding a new inference provider follows the sub-processor notice process on the Sub-processors page.

5. Currently admitted for Europe

Legal entities and transfer mechanisms are listed on the Sub-processors page.