blobhub blob revisions

Every revision of a blob, newest first, with the default marked and each phase shown

blob revisions lists every revision a blob has, newest first, marks the default, and shows each one’s phase and status. It is what turns a REVISION_NOT_WRITABLE failure into something self-diagnosing: the command that refused you named a phase, and this is where you see which revisions are in which.

Synopsis

blobhub blob revisions <org>/<blob>

Argument	Default	Description
blob	required	Blob as <org>/<name>, or a bare name with --org.

The command has no flags of its own. --org and --json are global, so they go before the subcommand.

What it does

1. Parses the reference, exactly as blob show does.
2. Fetches the blob record. Required, not enrichment: the listing itself does not report which revision is the default, so the * marker comes from the record’s default_revision_id.
3. Lists the revisions.
4. Prints one row per revision, newest first. The platform returns that order itself and the CLI keeps it rather than sorting again.

  REVISION                               PHASE     STATUS      CREATED                    COMMENT
* 9f2c1e84-3a77-4d10-b6e5-0c8a1f5d92b4   draft     ready       2026-07-14T09:12:03Z       add the refund branch
  1b6d4a09-52ee-4c31-8f77-a3d90b7e6c15   commit    ready       2026-06-30T16:40:55Z       v3
  c74e0b2d-8f19-4a63-9d02-5e1b8c47af38   commit    ready       2026-06-02T11:05:18Z       initial revision

An empty listing prints nothing at all — not even the header — and exits 0. A bare column header over no rows is noise a pipeline has to filter back out.

Under --json the payload carries blob and revisions, each entry holding id, phase, status, created_at, comment, parent_id and the boolean default. parent_id is in the JSON only; the rendered table leaves it out.

Phases, and which of them a command will accept

Phase	Read	Write
draft	yes	yes
managed	yes	yes
commit	yes	no

Both columns additionally require the revision’s status to be ready, which is what the STATUS column is for. There is no snapshot phase — it was never reachable through any endpoint and does not appear here.

This table is why the command exists in the shape it does. The platform’s own rejection for an unusable phase is a 409 revision_not_writable (a bare 400 before this epic) whose message does not mention the revision at all, so the CLI pre-checks the phase before it writes anything and reports REVISION_NOT_WRITABLE locally, naming the phase it found. When you get that code, this listing is the answer to “then which revision can I write to?” — the phase column is right there, and * marks the one a manifest’s revision: default resolves to.

The listing is complete

GET /blobs/:org_id/:blob_id/revisions pages (see List Revisions), and this command drains the cursor to null before it prints, so the listing is always every revision the blob has — platform.revisions_per_blob bounds how many can exist, never how many are shown.

It terminates on the cursor and not on a short page, because the cursor is absent only once the query is exhausted: a final page can legitimately be exactly full.

Errors

Code	When
BLOB_REFERENCE_INVALID	The reference is empty, carries more than one /, has an empty org before the /, has no blob name, or is a bare name with no --org and no BLOBHUB_ORG.
BLOB_NOT_ACCESSIBLE	The blob record is absent, not visible to this key, or the key was rejected outright — one 403 covers all of it.
AUTH_INVALID	The revision listing itself was rejected. Rare: the blob record is fetched first, so a bad key normally surfaces on the row above.
CREDENTIALS_NOT_FOUND	No API key from flags, environment, or credentials file.
PROFILE_NOT_FOUND	BLOBHUB_PROFILE names a profile that is not stored.
INSECURE_CREDENTIALS_PERMISSIONS	credentials.yaml is readable by group or other.
API_RATE_LIMITED, API_TRANSIENT_ERROR, API_NETWORK_ERROR	A call failed after its retries.

The revisions route is gated on read, not admin — and that was confirmed against the deployed API with a non-admin key, not merely read off the handler. It matters: if it needed admin, this command would be useless to exactly the keys the platform tells automation to use, and the one command that explains a phase failure would be unavailable to the automation hitting it.

See also

• blobhub blob show — the blob record, and the default revision only.
• blobhub blob limits — the blob’s limits, platform.revisions_per_blob among them.
• Error codes — every code above, and the advisories alongside them.
• List Revisions — the route behind the listing.
• Commit Revision — how a draft becomes a commit.