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

# Introduction

> BlobHub REST API — the programmatic entry point into the platform.

## Overview

The **BlobHub REST API** is the primary programmatic surface of the platform. Everything you can do from the
[web application](https://blobhub.io/) — creating Organizations, managing Blobs, versioning Revisions,
running Workflow Executions, scheduling triggers, uploading ONNX models — is available as a REST endpoint.

The API is designed to be predictable: it uses resource-oriented URLs, standard HTTP verbs and status codes,
and JSON request and response bodies throughout.

## Base URL

All REST API requests are made against:

```
https://api.blobhub.io/
```

## Versioning

The API is versioned via a URL prefix. The initial release of the API surface is available under:

```
/v1/
```

A full request URL therefore looks like:

```
https://api.blobhub.io/v1/{resource}
```

Future breaking changes will be introduced under new version prefixes so that existing integrations continue
to work unchanged.

## Authentication

Every non-public request must be authenticated. BlobHub supports several authentication flows — Google
sign-in, anonymous sign-in, and token refresh — all documented under the
[Authentication](/rest-api/auth/google-signin) section. Programmatic clients can also authenticate using
[API Keys](/rest-api/shared/list-api-keys) scoped to an Organization or individual Blob.

See [Conventions](/rest-api/conventions) for how authentication headers and shared request patterns are
applied consistently across the API.

## What You Can Do

The REST API is organized around the platform's core primitives:

<CardGroup cols={2}>
  <Card title="Users" icon="user" href="/rest-api/users/get-user">
    Manage the current user profile, limits, and organization membership.
  </Card>

  <Card title="Organizations" icon="building" href="/rest-api/orgs/create-org">
    Create and administer Organizations and list the Blobs they own.
  </Card>

  <Card title="Blobs" icon="box-archive" href="/rest-api/blobs/get-blob">
    Read, update, and delete Blobs, and enumerate their Revisions and Metadata.
  </Card>

  <Card title="Revisions" icon="code-branch" href="/rest-api/revisions/get-revision">
    Drive the Draft → Commit → Snapshot lifecycle of Blob content.
  </Card>

  <Card title="API Keys & Members" icon="key" href="/rest-api/shared/list-api-keys">
    Manage programmatic access and team membership on Organizations and Blobs.
  </Card>

  <Card title="Operations" icon="gears" href="/rest-api/operations/get-operation">
    Track asynchronous, long-running actions across the platform.
  </Card>
</CardGroup>

Blob-type-specific operations — such as Workflow Definitions, Sessions, and Executions, Scheduler Schedules,
and ONNX model uploads — live under the [Blob Types](/blob-types/introduction) section.

## Conventions

Before writing your first integration, skim the [Conventions](/rest-api/conventions) page — it covers the
request/response format, error shapes, pagination, and identifier rules that apply across every endpoint.

## Real-Time Updates

For event streams that can't be expressed efficiently as polling — live Workflow Execution updates, Session
Events, state changes — BlobHub exposes a complementary
[WebSocket API](/web-socket/introduction).

## SDKs

If you are working in Python, the [BlobHub Python SDK](/sdk/introduction) wraps the REST API with a thin,
idiomatic client so you don't have to construct requests by hand.