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

# Surfaces

> The API, the web app, the SDK, the CLI and the worker: five ways in, one API behind them.

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>;

BlobHub has five ways in: the API, the web app, the SDK, the CLI and the worker. The last four are clients of the
first. Each calls the same REST API, with the same kinds of credential any other caller can hold, so nothing is
reachable only by clicking: a workflow deployed from the CLI is the same workflow the web app opens and the SDK runs.

## API

[`api.blobhub.io/v1`](/rest-api/introduction) serves REST for everything, with a key scoped to an organization or a
single blob. A key can also be scoped to a user, as a [service account](/general/service-accounts)'s own key is, and
then reaches whatever that user's memberships reach. Every key carries one role, fixed when it is minted. A person
in the web app signs in with Google instead and calls the same routes with a bearer token, and a visitor who never
signs in gets an anonymous, read-only token that reaches public content.

Beside it, the [WebSocket API](/web-socket/introduction) pushes a session's events to a subscriber as they happen, the
start and end of every run in the session among them; a run's progress component by component is written to its log
and never pushed. None of the surfaces below opens a WebSocket. Each one pages the recorded logs instead, as
[Architecture](/general/architecture#live-updates) explains.

## Web

[blobhub.io](https://blobhub.io) is the web app: the workflow editor, the debugger, playgrounds and apps. Its
[Gallery](https://blobhub.io/gallery) lists public workflows to start from, [Apps](https://blobhub.io/apps) the apps
built on BlobHub, and [Labs](https://blobhub.io/labs) public models, graphs and datasets. In your own organizations you
manage blobs, build a workflow in the editor, follow its runs in the debugger and drive a session from a playground.
Settings cover members, API keys, credentials and limits, for an organization or a single blob, as well as service
accounts and your own profile.

Every change a screen makes to your work is a REST call another client could make, as Architecture's
[Principles](/general/architecture#principles) show by example; preferences such as the theme, pane widths and the
revision you picked stay in the browser. A screen that updates on its own does it by polling the API; nothing is
pushed to the browser.

<Shot src="/general/images/surfaces/web.png" alt="The BlobHub web app on a workflow" caption="The web app is one client of the same REST API every other surface uses." />

## SDK

`pip install blobhub` installs the [Python SDK](/sdk/introduction), for running workflows and reading their record
from Python and notebooks. Its workflow module runs a definition that is already deployed, in a session you name or
in a fresh one, waits for the run while reading its event log, and can stop it; writing and deploying definitions is
the CLI's job. A generic layer reaches blobs, revisions and any type's data commands, and typed modules cover ONNX
models in full and run statements against graphs. Credentials resolve the way the CLI's do, from an argument, the
environment or a shared profile, and with no key the SDK falls back to an anonymous token that reads public content.
Its example notebooks ship inside the package: `python -m blobhub.notebooks` lists them and copies one out.

## CLI

`pip install blobhub-cli` installs the [CLI](/cli/introduction), the `blobhub` binary, for building, versioning and
deploying workflows and schedules from a terminal or CI. A workflow's code is an ordinary local Python package, with
real imports and tests, which the CLI compiles into the flat namespace a code component runs. A manifest in your
repository lists a workflow's definitions against their source files, or a scheduler's schedules field by field, so
both are versioned with the rest of your code. `deploy` writes only what changed, `diff` shows what would change, and
anything on the platform the manifest does not mention is reported and left alone, never deleted by a deploy.
`workflow execute` starts a run and, with `--watch`, polls its events for up to fifteen minutes. In CI the key can
come from an environment variable, with nothing stored on disk.

<Shot src="/general/images/surfaces/cli-deploy.svg" alt="blobhub workflow deploy in a terminal" caption="The CLI keeps a workflow in your repository and deploys it from a terminal or CI." />

## Worker

`pip install blobhub-worker` installs the [worker](/worker/introduction), which runs Claude Code, Codex and
Antigravity on your own machines, inside your guardrails. It attaches to a workflow session, runs a coding agent for
each thread a caller marks pending, and posts every turn back to the thread as items. Each agent runs under a
permission posture: a person approves each gated call, a policy decides most of them, or nothing is gated. The worker
authenticates with an API key, as the CLI does, and calls the REST API over HTTPS, polling for work, so it needs no
inbound connection. [Agents & workers](/general/agents-and-workers) and
[Policies & approvals](/general/policies-and-approvals) cover what it runs and what holds it back.

## Widgets

`widgets.blobhub.io` serves one embeddable widget, a published view of a graph. A graph blob's **Publish** tab saves a
view, a list of OrientDB SQL queries, and hands out the widget's URL as an `<iframe>` snippet that renders the view in
another page. The widget never signs anyone in, so it shows only public graphs, and the graph type it belongs to is
legacy: a new organization cannot create a graph blob unless the type is enabled for it. The widget renders a graph
and nothing else; an agent or a workflow is reached through the REST API.


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