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

# Update Blob

Update a blob's profile and settings.

## **PATCH** `/blobs/:org_id/:blob_id`

### Path Parameters

| Parameter | Type   | Required | Description                        |
| :-------- | :----- | :------- | :--------------------------------- |
| `org_id`  | string | Yes      | The unique ID of the organization. |
| `blob_id` | string | Yes      | The unique ID of the blob.         |

### Request Body

| Parameter     | Type   | Required | Description               |
| :------------ | :----- | :------- | :------------------------ |
| `visibility`  | string | No       | `public` or `private`.    |
| `name`        | string | No       | Display name of the blob. |
| `description` | string | No       | Description of the blob.  |
| `url`         | string | No       | External URL.             |
| `tags`        | array  | No       | List of string tags.      |

### Response

Returns `{"status": "success"}` — no body beyond the status.

### Errors

| Status | Error                  | Cause                                                                                                                  |
| :----- | :--------------------- | :--------------------------------------------------------------------------------------------------------------------- |
| 400    | `invalid_request_body` | An unknown field, or a value of the wrong type.                                                                        |
| 403    | `forbidden`            | Missing `write` access to the blob, the blob does not exist, or — for `visibility` only — no human behind the request. |

A blob the caller cannot see is reported as `403`, not `404`: the API does not distinguish "absent" from
"not yours."

### Changing Visibility

`visibility` is the one field on this endpoint that moves the access perimeter: flipping a blob to `public`
exposes its content to anonymous readers, and anonymous tokens are freely obtainable. Changing it therefore
requires a human behind the request, and a [service account](/general/service-accounts)'s own key is refused
with `403` — even though the endpoint as a whole only needs `write`, two role levels below every other
perimeter operation.

The guard is narrower than the endpoint, in two ways that matter:

* **It is on the field, not the request.** `name`, `description`, `url` and `tags` are ordinary product work.
  A service account can PATCH any of them, alone or together, and is never refused.
* **It is on an actual change, not on the field's presence.** Sending `visibility` with the value already
  stored moves nothing and is allowed. This is deliberate: an idempotent client that PATCHes its whole desired
  state on every run would otherwise be refused forever for writing back a value that changes nothing.

Both directions are governed — `private` → `public` and `public` → `private` alike. **Creating** a blob is
untouched whatever visibility it is created with, because a new public blob exposes only content the account
itself authored; only changing an existing blob's visibility is governed. Use an
[acting token](/rest-api/auth/impersonate) when automation has to publish or unpublish on a human's behalf.

### Example

<CodeGroup>
  ```json Request theme={null}
  {
    "description": "Updated description",
    "tags": ["latest", "production"]
  }
  ```

  ```json Response theme={null}
  {
    "status": "success"
  }
  ```
</CodeGroup>