Skip to main content
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. 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, 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 and Delete Credential are the routes.

​
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 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 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.