Skip to main content
Update a blob’s profile and settings.

​
PATCH /blobs/:org_id/:blob_id

​
Path Parameters

​
Request Body

​
Response

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

​
Errors

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’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 when automation has to publish or unpublish on a human’s behalf.

​
Example