> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blobhub.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Credentials

> Third-party secrets the platform uses on your behalf and that no API route returns.

export const Shot = ({src, alt, caption}) => <Frame caption={caption}>
    <img className="block dark:hidden" src={src} alt={alt} />
    <img className="hidden dark:block" src={src.replace(/\.(png|svg)$/, '.dark.$1')} alt={alt} />
  </Frame>;

A credential is a secret for a system outside BlobHub, such as a model provider, a vector database or a search
service, stored on the platform so a workflow can call that system by naming the credential instead of carrying the
secret.

It is a different thing from an [API key](/general/organizations-and-access#api-keys). A key is how a caller proves
who it is to BlobHub; a credential is a secret BlobHub holds so it can reach somewhere else on the caller's behalf.

## Where a credential lives

A credential is stored on a user, an organization or a blob, and the settings of each have a **Credentials** section
that lists, adds and deletes them. Reaching a target's credentials takes `admin` on it. Storing or removing one also
needs a person behind the request, because it hands a target the keys to another system: that puts it on
[the access perimeter](/general/organizations-and-access#the-access-perimeter), so a service account's own key is
refused even where its membership says `admin`.

Each credential names its provider from a fixed catalog: OpenAI, Anthropic, Google Gemini, Pinecone, Firecrawl,
Tavily, or a generic one for any other service. Its secret is checked against that provider's shape when it is
stored, so a malformed one is refused then rather than at the first run that needs it. It also carries an alias,
unique among the credentials on its target, and an optional description; both tell credentials apart and say
nothing about the secret. [Create Credential](/rest-api/shared/create-credential) and
[Delete Credential](/rest-api/shared/delete-credential) are the routes.

<Shot src="/general/images/credentials/credentials.png" alt="An organization's stored credentials, by alias and provider" caption="A credential's secret is never shown again once it is stored." />

## How a run uses one

A definition never holds a credential's id. A component that calls an outside service names the credential it needs
by alias, and the platform resolves that alias when a run reaches the component, against the target of whoever
started the run: the person's own user when they start it signed in, the key's target when an API key starts it, and
whoever created the schedule for a scheduled fire. [Components](/blob-types/workflow/workflows/components) lists the
components that call outside services.

So the credential a run uses belongs to whoever ran it, never to whoever wrote the definition. A shared workflow never
runs with its author's credentials: one that names an alias works only where the person or key running it holds a
credential of that alias. If the alias names no credential there, the component fails with an error event naming the
alias and takes its `failure` route; it never calls the service without one.

## Not returned by the API

No credential route returns the secret, and the API offers no way to read one back once it is stored. A code
component wired to a provider is where that stops holding: its Python can read the provider's credential inside its
run, which is what the generic provider is for, and whatever that code writes, an output or a session object, can
carry the secret with it.

[List Credentials](/rest-api/shared/list-credentials) returns each credential's id, provider, alias and description,
and deleting one confirms only that it is gone. A secret you no longer have is replaced by storing a new credential,
not recovered.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.