One API for all of it

Everything you build here is reachable from outside it. Your personas - with their voice, the procedures you attached and what they remember about you - answer on an endpoint that speaks the OpenAI API, so the client you already use works without a plugin, an adapter or a rewrite.

It is the API your tools already speak

Point Open WebUI, LibreChat, a Python script or your own application at it and list the models. What comes back is your roster: each persona you marked for the API, by name. Send a chat completion naming one and you get that persona - not a bare model wearing its prompt, but the whole thing: the tools it may use, the skills you attached, and what it remembers about you.

Long conversations stay affordable. An OpenAI client is stateless, so it resends the whole thread on every call; the endpoint summarizes the older part of that replay to fit the model rather than letting the bill grow with every turn.

Streaming works the way clients expect, so a long answer arrives token by token rather than as a pause followed by a wall of text.

The personas on the API carry the decision tools too. Ask one to judge whether a page is worth reading, which of three answers to lead with or how ready a draft is, and it puts the question to the decision model and quotes the probability back, on the same key and in the same ledger.

A key carries your permissions, and nothing more

You mint a key on your security page, name it, and it is shown once. It carries your own visibility: a key can never reach a persona you could not already open, and it cannot be pointed at a colleague's work or another organization's. Revoking it is immediate, and disabling it is reversible while you work out where a leak came from.

Keys are scoped to one surface, so what a compromised key can do is a question with a short answer.

Your account pays, at your rates

Calls arriving over the API run on your organization's own provider credentials, exactly as calls from the web interface do. There is no token resale in between and no separate metering to reconcile - API usage lands in the same ledger, priced in real money, sliced by model and by the application that made the call.

Whichever model you point it at

The model name a client asks for is the persona; the model that answers is whichever you configured behind it. Each persona is backed by a harness, and each harness by an endpoint you own - an OpenAI-compatible server on your own hardware, Anthropic directly, Amazon Bedrock on your own AWS account, or Venice.ai, whose hundred-plus text models all sit behind one key. Repoint the endpoint and the same persona keeps answering on a different model, and every client calling it carries on unchanged. Several of the personas answering on this site's own API run on Venice today.

A provider's limits are honoured rather than passed to you as an error. Venice accepts at most twenty tool definitions in a request, so a persona carrying more has its toolbelt trimmed to fit instead of failing the call, and its privacy and thinking parameters are sent explicitly so no provider default is quietly prepended to the prompt you wrote.

Jarvis, on the same terms

Your organization's own agent has a surface of its own. Ask for jarvis, jarvis-fast or jarvis-deep and the Jarvis from the voice room answers: the same memory of you, the skills it has learned, your meetings and its missions. Each chat continues its own conversation, and the setup page for Open WebUI publishes it to your whole instance in two steps. It is included from the Standard plan, beside the personas API.

Where it starts

The personas API is included from the Standard plan. There is a live reference page inside the app where you can authenticate with your own key and run a request against your own personas in the browser before writing a line of code.

The surface around it

An integration you cannot inspect is one you cannot trust. Every surface here is documented, versioned and testable from inside the app with your own credentials.

Reference pages you can actually use

Each surface ships an OpenAPI schema and a live reference page. Authorise with a real key, expand an endpoint, send the request, read the response - the same request your code will make, against your own data, before you commit to anything. There is a ReDoc rendering alongside it for reading rather than poking.

One key, one job

Keys are minted per surface. A key issued for personas is refused by any other endpoint even when the person holding it is entitled to both, so revoking one has a blast radius you can predict rather than discover.

Name them for what they are - the client, the script, the machine - and the list tells you when each was last used. Switch one off while you investigate something and switch it back on; the token survives. Delete it and it does not.

Rate limits that protect you from your own automation

Every plan carries per-minute ceilings on requests and tokens, plus a limit on how fast any single conversation may turn. That last one is the useful one: an agent that loops is the ordinary way a month's budget disappears in an afternoon, and it is caught in seconds rather than at the invoice.

Three surfaces, and why each exists

The personas API is chat against the colleagues you built. The Jarvis API is your own agent, with everything it knows about you and your work. The teams API runs a whole multi-agent crew as one call, for work that needs several roles in conversation rather than one voice answering.

There is deliberately no fourth for customers. Raw model-configuration access stays with platform staff: it would give you nothing the personas surface does not, on the same models, minus the voice, memory and skills that make an endpoint worth naming.