> ## 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. # blobhub blob show > The blob record and the phase of its latest revision, for a blob of any domain in any phase `blob show` answers what a reference actually points at: the blob record — id, org, domain, type, format, visibility, status — and the phase of its latest revision. Two read-only calls, no manifest, no local state. Reach for it when a command that *does* take a manifest has just refused the blob. `show` applies none of the gates that refusal came from, so it still answers. ## Synopsis ```bash theme={null} blobhub blob show / ``` | Argument | Default | Description | | -------- | -------- | ---------------------------------------------------- | | `blob` | required | Blob as `/`, or a bare name with `--org`. | The command has no flags of its own. `--org` and `--json` are [global](/cli/configuration#global-flags), so they go **before** the subcommand: ```bash theme={null} # a bare name inherits the org from --org, or from BLOBHUB_ORG blobhub --org acme blob show dragon-ops ``` ## What it does 1. Parses the reference. A bare name takes the org from `--org` or `BLOBHUB_ORG`; more than one `/`, an empty org before the `/`, or an empty blob name is `BLOB_REFERENCE_INVALID`. 2. Fetches the blob record. A `403` here is `BLOB_NOT_ACCESSIBLE`. 3. If the record names a latest revision, fetches it for its phase and status. **This call is enrichment**: any failure leaves the revision block unresolved and the command still exits `0`, because the record is already an answer. 4. Prints one field per line: ```text theme={null} Blob: acme/dragon-ops Alias: dragon-ops Id: Org: Domain: workflow Type: generic Format: blobhub Visibility: private Status: ready Latest: phase draft, status ready, created 2026-07-14T09:12:03+00:00 ``` Under `--json` the same payload carries `blob` (the `/` label, qualified even when your reference was bare), `record`, and `latest_revision` — `null` when the revision was not resolved — alongside the envelope's `schema_version`. ### The three readings of `Latest:` | What you see | What it means | | ------------------------------------------------------------------- | ------------------------------------------------------- | | A revision id and a `phase … status … created …` line | Both calls succeeded. | | A revision id, then `(revision details not readable with this key)` | The blob names a latest revision and reading it failed. | | `(none)` | The blob has no revision at all. | The last two are distinct on purpose. One says mint a better key; the other says this blob has never had a revision, and blaming the key for that is a wrong answer. ## What it deliberately does not check Every manifest-driven command — `workflow deploy`, `workflow diff`, `scheduler deploy`, all of them — resolves its blob through one shared resolver, and that resolver applies two gates before it returns a target. `blob show` applies **neither**. | Gate | A manifest-driven command | `blob show` | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | ------------------------------------------- | | **Blob shape.** `domain`/`type`/`format` must equal the group's expected shape exactly: `workflow`/`generic`/`blobhub` for the `workflow` group, `scheduler`/`generic`/`blobhub` for `scheduler`. | Refuses with `BLOB_NOT_WORKFLOW`. | Prints the shape and carries on. | | **Revision phase and status.** A write needs status `ready` and phase `draft` or `managed`; a read also allows `commit`. | Refuses with `REVISION_NOT_WRITABLE`. | Prints the phase and status and carries on. | An inspector has to answer for a blob of any domain in any phase, and the states a deploy refuses are precisely the states someone runs `show` to diagnose. If `workflow deploy` told you the blob is not a workflow blob, `show` is what tells you what it is instead. If it told you the revision cannot be written, `show` is what tells you the phase it is actually in. `show` reports the latest revision only. For every other revision, and for which phases allow what, use [`blobhub blob revisions`](/cli/blob/revisions). ## 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 is absent, or not visible to this key. The platform answers the same `403` for both, so the message names both and asserts neither. | | `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` | The record call failed, after its retries. | That table leaves two things implicit, and both are worth stating outright. **A rejected key also arrives as `BLOB_NOT_ACCESSIBLE`.** The client raises one error for `401` and `403` alike, and the blob fetch translates it. That is why the hint on this code is `blobhub whoami` rather than `blobhub login` — run it, and if the key is fine the blob really is the problem. **When the org segment is not a UUID, the message adds one more clause:** an org-scoped key must address its org by UUID, not by alias, because the platform's target check is a raw string comparison against the org UUID. An org alias yields exactly this `403` on every call. `AUTH_INVALID` cannot surface from `show`. The only call that can be rejected is translated above, and the revision read swallows every failure it sees. ## See also * [`blobhub blob revisions`](/cli/blob/revisions) — every revision and its phase, when the latest is not the one you need. * [`blobhub blob limits`](/cli/blob/limits) — the same blob's limits, for a key that may read them. * [Get Blob](/rest-api/blobs/get-blob) and [Get Revision](/rest-api/revisions/get-revision) — the two routes behind the output. * [Concepts](/cli/concepts) — why absent and inaccessible are the same `403`. * [Error codes](/cli/error-codes) — the full catalog behind the table above, remediation included.