Avatar
Package account is your own account: API keys you mint and revoke, and org onboarding.
Package account is your own account: API keys you mint and revoke, and org onboarding.
| Base URL | https://api.hanzo.ai |
| Operations | 2 |
| Auth | Authorization: Bearer $HANZO_API_KEY |
avatar
GET /v1/avatar/{org}/{user}/{digest}
Fetch a profile photo
Streams a profile photo's raw BYTES. This is the address stored on the user's IAM record and rendered directly by an <img>, so it takes no credentials — the 64-hex content digest in the path is the capability, and it can only be produced by someone who already has the image.
The Content-Type is derived from the stored bytes and the response carries nosniff, so only a real raster image is ever served and only under its true type. Anything else — a miss, a malformed path, an object that is not an image — is one 404, and a hit caches for a year because the address is the content.
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
org | path | string | yes | |
user | path | string | yes | |
digest | path | string | yes |
POST /v1/avatar
Set your profile photo
Stores one image as the signed-in user's profile photo and answers the URL it is served from, which is also written to the user's IAM record — so every surface that already renders avatar picks it up with no further call.
The body is a multipart form with a file part. The format is decided by the BYTES, never the filename or the part's Content-Type: png, jpeg, gif and webp are accepted and everything else is refused with 415, so an SVG cannot be stored as a picture and later served as a program. Over 8 MiB is 413; empty is 400.
The photo is addressed by the sha256 of its bytes, so setting a new one yields a new URL rather than a stale cache of the old face. The caller is taken from the validated identity ONLY — there is no way to name a different subject — so this always sets your own photo, and a caller with no organization yet is refused.
How is this guide?