Platform API

The Platform API is the infrastructure layer: one endpoint, many models, EU-sovereign by default, with per-tenant metering and a model policy that is enforced in code rather than promised in a contract.

If you have an application that already talks to an OpenAI-compatible API, the change is the base URL.

What you get

One endpoint, many models. Open-weight models on EU infrastructure plus frontier models where your policy allows them — same request shape either way.

A policy that is enforced, not documented. Requests declare a tier (eu-sovereign, frontier, cheapest) and whether they carry personal data. A request marked as carrying personal data is refused a non-EU model centrally, and every model choice is logged — the evidence trail an EU AI Act file needs.

Metering per tenant. Usage is attributed to the tenant that caused it, so a multi-customer product can bill its own customers without building a metering layer first.

Managed retrieval. Ingest text and PDFs, get chunking, embeddings and vector storage; query with citations. No separate vector database to operate.

A batch tier. Non-urgent bulk jobs submit and poll, at roughly half the price — the provider’s batch discount, passed through.

Where to start

The full endpoint reference — request shapes, model list, RAG, batch and the policy fields — lives in HTTP API — Multi-LLM, RAG, Batch.

For key handling and how a request is attributed to a tenant, see Storing credentials and BYO API keys.

Access

Self-service API keys are in early access: the gateway is live and usable, per-organisation keys and the workspace key flow are still being finished. If you want to build against it now, say so and we will set you up.

How it relates to the rest

The API is the same layer everything else on the platform runs on — the chat, the apps, and the Autopilot departments all speak to it. What you get is direct access to that layer, with the same jurisdiction guarantees and the same audit trail.