> For the complete documentation index, see [llms.txt](https://docs.otari.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.otari.ai/learn/provider-keys.md).

# Provider Keys

Provider keys are the upstream credentials your organization uses to call LLM providers like OpenAI, Anthropic, or Mistral. They live at the organization level. Workspaces inherit provider access by default and can pin or disable keys per provider.

***

### Two ways to get provider access <a href="#h_7645da3afa" id="h_7645da3afa"></a>

#### Otari-managed keys

Use the Mozilla.ai inference catalog without bringing your own key material. Otari handles the upstream credential, and usage is billed against your wallet balance.

#### Your own keys

Bring your existing provider API keys and let Otari use them on your behalf. The upstream provider bills you directly, and Otari adds no per-token routing charge.

Most organizations use a mix. Managed keys are convenient for catalog models. Your own keys are for specific accounts, contracts, or providers not in the catalog.

***

### How workspaces resolve provider keys <a href="#h_0685da12ce" id="h_0685da12ce"></a>

When a workspace makes a request, Otari resolves which provider key to use in this order:

1. If the workspace has a key pinned for the provider, use that.
2. Otherwise, use the organization default key for that provider.
3. If the workspace has explicitly disabled the org default, the request fails for that provider.

This means a workspace inherits everything by default but can opt out of specific keys or override defaults per provider.

***

### Provider keys vs API Keys <a href="#h_a75c65bc43" id="h_a75c65bc43"></a>

These are two different things, and the naming is unfortunately close:

* **Provider keys** are your upstream credentials, like your OpenAI or Anthropic key, that Otari uses to call providers. They are managed at the organization level.
* **API Keys** are the workspace-scoped tokens your application sends to otari.ai. They are managed per workspace.

{% hint style="info" %}
Your application sends an API Key to Otari. Otari uses a provider key to call the upstream provider. The application never sees the provider key.
{% endhint %}

***

### How security works <a href="#h_3be0e32ffa" id="h_3be0e32ffa"></a>

* **Organization scope**. Provider keys are owned by the organization, not copied into each workspace.
* **Workspace controls**. Each workspace decides which organization keys are effective for its workloads.
* **Role gating**. Only admins and owners can add or remove provider key material, or change which keys a workspace can access.
* **Runtime resolution**. Otari resolves the right provider key at request time. The workspace's API Key never carries the upstream secret.

{% hint style="warning" %}
Removing a provider key from Otari does not revoke it with the upstream provider. After deleting a key from Otari, also revoke it in the provider's dashboard.
{% endhint %}

Ready to create a key?

{% content-ref url="/pages/d9d593aeabc52a165190bf8c93720491a4eb9682" %}
[Manage provider keys](/how-to-guides/manage-provider-keys.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.otari.ai/learn/provider-keys.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
