Docker Hub

Delete a personal access token. DELETE /v2/access-tokens/{uuid}. Permanently revokes one personal access token. Every Docker CLI login, CI job and integration still using that token stops authenticating immediately, and Docker cannot re-issue the same value -- a replacement is a new token with a new value that has to be distributed. Irreversible. Confirm the uuid against the list call before calling this, and note that deleting the token THIS connection was made with disconnects the connection itself. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Docker serves the personal-access-token management API to a session token obtained by signing in with a PASSWORD. This integration never accepts a Docker password -- a connection holds an access token and nothing else -- and whether an ORGANIZATION access token reaches a user's PERSONAL tokens is unmeasured. So expect this operation to be unavailable on either credential a connection can carry. It is shipped rather than withheld because Docker's own 403 names the cause exactly, and because the organization-token side has not been disproved.

Cancel an invite. DELETE /v2/invites/{id}. Withdraws a pending organization invitation, so the link in the invitee's email stops working. Irreversible: inviting them again is a new invite with a new id. The id comes from the pending-invites listing. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Delete an organization access token. DELETE /v2/orgs/{org_name}/access-tokens/{access_token_id}. Permanently revokes one organization access token. Every pipeline, registry client and integration authenticating with it stops working immediately, and Docker cannot re-issue the same value. Irreversible. Read the token first to see which repositories it reaches before removing it -- and note that deleting the token THIS connection was made with disconnects the connection itself. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Delete a team. DELETE /v2/orgs/{org_name}/groups/{group_name}. Removes the team from the organization. Every repository grant made to that team goes with it, so its members lose whatever access they held THROUGH the team -- while remaining members of the organization. Irreversible: re-creating a team of the same name gives it a new numeric id and no grants. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Remove a user from a team. DELETE /v2/orgs/{org_name}/groups/{group_name}/members/{username}. Takes one person out of one team. They lose every repository permission the team carried but stay a member of the organization and of any other team. Irreversible through this API; re-adding them is a separate call. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Remove a member from the organization. DELETE /v2/orgs/{org_name}/members/{username}. Revokes a person's membership. They lose access to every private repository the organization owns and to every team they were in, immediately. Irreversible through this API -- restoring them means a fresh invite they must accept, and their team memberships are not restored with it. Removing the last owner can leave the organization unadministrable. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

List personal access tokens. GET /v2/access-tokens. Returns the Docker account's personal access tokens, one page at a time, each with its label, uuid, scopes, creation time, expiry, whether it is active and when it was last used. This is the inventory call: use it to find the uuid a later read, rename, deactivation or deletion names. The token VALUE is never returned here: Docker redacts it as `***` on every response after creation, and this integration redacts the field again on the way out so a spec omission cannot leak one. The two operations that DO mint and return a live token value are not shipped as tools at all. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Docker serves the personal-access-token management API to a session token obtained by signing in with a PASSWORD. This integration never accepts a Docker password -- a connection holds an access token and nothing else -- and whether an ORGANIZATION access token reaches a user's PERSONAL tokens is unmeasured. So expect this operation to be unavailable on either credential a connection can carry. It is shipped rather than withheld because Docker's own 403 names the cause exactly, and because the organization-token side has not been disproved.

Get a personal access token. GET /v2/access-tokens/{uuid}. Returns one personal access token by uuid: its label, scopes, creation time, expiry, active flag and last use. The token VALUE is never returned here: Docker redacts it as `***` on every response after creation, and this integration redacts the field again on the way out so a spec omission cannot leak one. The two operations that DO mint and return a live token value are not shipped as tools at all. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Docker serves the personal-access-token management API to a session token obtained by signing in with a PASSWORD. This integration never accepts a Docker password -- a connection holds an access token and nothing else -- and whether an ORGANIZATION access token reaches a user's PERSONAL tokens is unmeasured. So expect this operation to be unavailable on either credential a connection can carry. It is shipped rather than withheld because Docker's own 403 names the cause exactly, and because the organization-token side has not been disproved.

List audit log events. GET /v2/auditlogs/{account}. Returns the account's audit trail: who did what, to which object, when, and from where. Filter by `action` (use the audit-log actions call for the valid names), by `name` (the repository or organization the event is about), by `actor` (the user who triggered it) and by a `from`/`to` time window. Paged. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

List audit log actions. GET /v2/auditlogs/{account}/actions. Returns the action names this account's audit log can record, grouped by the object they act on (repository, organization, team, billing, ...). Call this first: the names it returns are exactly the values the audit-log events call accepts in its `action` filter, and a filter value that is not one of them silently matches nothing. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

List repositories in a namespace. GET /v2/namespaces/{namespace}/repositories. Returns the repositories owned by one Docker user or organization, with each one's description, privacy, pull and star counts and last-updated time. Filter by partial `name`, order with `ordering`, and page with `page`/`page_size`. An empty `results` array is a real answer: it means the namespace owns no repository this credential can see. Note that Docker narrows this listing rather than refusing it when the credential lacks repository-list scope, so an unexpectedly short page is a scope question, not an outage.

Get a repository. GET /v2/namespaces/{namespace}/repositories/{repository}. Returns one repository: its descriptions, privacy, type, status, star and pull counts, affiliation and last-updated time. A repository that does not exist -- or that this credential cannot see, which for a private repository is the same answer -- gives `404 object not found`. Verified 2026-09-17.

List repository tags. GET /v2/namespaces/{namespace}/repositories/{repository}/tags. Returns the tags published in one repository, each with its digest, total size, last-pushed time, the user who pushed it and the per-architecture images behind it. Paged, up to 100 per page. Measured 2026-09-17: a repository that exists but has never been pushed to answers 200 with `count: 0` and an empty `results` array, while a repository that does not exist answers `404 object not found` -- so an empty page is a real answer about a real repository, not a missing one.

Read a repository tag. GET /v2/namespaces/{namespace}/repositories/{repository}/tags/{tag}. Returns one tag: its content digest, size, when it was last pushed and by whom, and the list of per-architecture images it resolves to (os, architecture, variant, digest, status). This is how you turn a moving tag such as `latest` into the immutable digest it currently points at. A tag that has never been pushed answers `404 object not found`.

List organization access tokens. GET /v2/orgs/{name}/access-tokens. Returns the organization's access tokens one page at a time, each with its label, id, creator, creation time, expiry, active flag and last use. Organization access tokens are the credential that reaches this administration plane at all, so this is how you audit who holds one. The token value is not part of this response at all -- Docker's own schema has no field for it. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Get organization settings. GET /v2/orgs/{name}/settings. Returns the organization's Registry Access Management posture: whether image usage is restricted for its members, and if so whether Docker Official Images and Verified Publisher images are still allowed. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Get an organization access token. GET /v2/orgs/{org_name}/access-tokens/{access_token_id}. Returns one organization access token with the RESOURCES it may reach -- each a repository or organization path plus the scopes granted on it (`scope-image-pull`, `scope-image-push`, `scope-repository-create`, ...). That resource list is the token's real blast radius and is not in the list call. The token value is not returned. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

List organization teams. GET /v2/orgs/{org_name}/groups. Returns the organization's teams (Docker calls them groups) with each one's numeric id, name, description and member count. The numeric id is what the repository-access grant needs. Narrow the list with `username` to find the teams one person is in, or with `search`. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Get a team. GET /v2/orgs/{org_name}/groups/{group_name}. Returns one team by name, with its numeric id, description and member count. This is where the `group_id` the repository-access grant needs comes from. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

List team members. GET /v2/orgs/{org_name}/groups/{group_name}/members. Returns the people in one team, with their Docker ID, full name and email. Paged, and searchable by username, full name or email. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

List pending organization invites. GET /v2/orgs/{org_name}/invites. Returns the invitations sent but not yet accepted, each with its id, the invitee, the inviting user and the team the invitee would join. The ids it returns are what the cancel and resend calls name. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

List organization members. GET /v2/orgs/{org_name}/members. Returns the people in an organization with their Docker ID, full name, email, role and whether their seat is active. Filter by `role` (`owner`, `editor`, `member`), by `type` (`member`, `invitee`, `all`) and by a `search` term, and optionally fold pending invites into the same page with `invites`. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Export organization members as CSV. GET /v2/orgs/{org_name}/members/export. Returns the organization's whole membership as a CSV document rather than a JSON page -- the shape for a seat audit or a licence reconciliation. Not paged: it is the entire roster in one response, so it carries every member's email address. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Check whether a repository exists. HEAD /v2/namespaces/{namespace}/repositories/{repository}. The headers-only form of the repository read: 200 means it exists and this credential can see it, 404 means it does not or cannot. Returns NO BODY -- this integration answers with an empty document and the status is the whole result. Verified 2026-09-17.

Check that a repository has tags. HEAD /v2/namespaces/{namespace}/repositories/{repository}/tags. The headers-only form of the tag listing: measured 2026-09-17, 200 means the repository EXISTS -- whether or not it has any tag, since the GET answers 200 with `count: 0` for an untagged one -- and 404 means the repository does not exist. Returns NO BODY at all -- this integration answers with an empty document and the status is the whole result. Use it when only the existence question matters; use the GET when you need the tags.

Check whether a tag exists. HEAD /v2/namespaces/{namespace}/repositories/{repository}/tags/{tag}. The headers-only form of the tag read: 200 means the tag is published, 404 means it is not. Returns NO BODY -- this integration answers with an empty document and the status is the whole result. Cheaper than the GET when you only need to know whether a build has already been pushed.

Update a personal access token. PATCH /v2/access-tokens/{uuid}. Renames a personal access token or deactivates it. Sending `is_active: false` stops the token authenticating without deleting it, which is the reversible half of revocation -- unlike the delete, a deactivated token can be switched back on. The token's SCOPES cannot be changed: Docker fixes them when the token is minted. The token VALUE is never returned here: Docker redacts it as `***` on every response after creation, and this integration redacts the field again on the way out so a spec omission cannot leak one. The two operations that DO mint and return a live token value are not shipped as tools at all. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Docker serves the personal-access-token management API to a session token obtained by signing in with a PASSWORD. This integration never accepts a Docker password -- a connection holds an access token and nothing else -- and whether an ORGANIZATION access token reaches a user's PERSONAL tokens is unmeasured. So expect this operation to be unavailable on either credential a connection can carry. It is shipped rather than withheld because Docker's own 403 names the cause exactly, and because the organization-token side has not been disproved.

Update repository immutable-tag rules. PATCH /v2/namespaces/{namespace}/repositories/{repository}/immutabletags. Turns immutable tags on or off for one repository and sets which tag names are protected, as a list of Go regular expressions. A tag matching a rule can never be overwritten or deleted once pushed, which is what makes a release tag trustworthy -- and is also why a mistaken rule is expensive: a build pipeline that re-pushes a protected tag starts failing, and the tag itself cannot be cleaned up. Both fields are REQUIRED and this replaces the whole rule list, so send the rules you want to keep. Test a rule against a tag name with the immutable-tag verify call before saving it.

Update an organization access token. PATCH /v2/orgs/{org_name}/access-tokens/{access_token_id}. Renames an organization access token, deactivates it, or changes WHICH repositories it reaches and with what scopes. The `resources` list is a replacement, not an addition: whatever you send becomes the token's entire reach, so send its current resources back alongside any new one, or the omitted ones are revoked. `is_active: false` suspends the token reversibly, unlike the delete. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Update some of a team's details. PATCH /v2/orgs/{org_name}/groups/{group_name}. Changes the team's name, description or default role without having to resend the others -- the partial counterpart to the replace call, and the right one for a description-only edit. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Invite people to an organization. POST /v2/invites/bulk. Invites several people at once by email address or Docker ID, optionally straight into a team and with a role. Each invitation sends a real email and, once accepted, consumes a paid seat -- so run it with `dry_run: true` first, which validates every invitee and changes nothing. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Resend an invite. PATCH /v2/invites/{id}/resend. Sends the invitation email again for a pending invite -- the call for an invitation that was never received or has been lost. The invite keeps its id. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Create a repository. POST /v2/namespaces/{namespace}/repositories. Creates an empty image repository in a user or organization namespace and returns it. It holds no image until something is pushed to it with the Docker CLI -- this API creates the repository record, not its contents, so a tag listing on a fresh one answers 404. `is_private` defaults to false, which means the repository and everything later pushed to it are visible to the whole internet: set it explicitly rather than relying on the default. Verified 2026-09-17.

Verify an immutable-tag rule. POST /v2/namespaces/{namespace}/repositories/{repository}/immutabletags/verify. Checks one Go regular expression against the repository and reports which existing tags it would protect. Changes nothing -- it is the dry run for the immutable-tag update, and the right call to make before committing a rule that cannot be undone for tags already pushed.

Create a team. POST /v2/orgs/{org_name}/groups. Creates an empty team in the organization and returns it with the numeric id that later calls use. A team is how repository access is granted to several people at once: create it, add members, then grant it access to repositories. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Add a member to a team. POST /v2/orgs/{org_name}/groups/{group_name}/members. Puts an EXISTING organization member into a team, which grants them every repository permission that team holds. It does not invite anyone: the person must already be a member of the organization -- use the bulk invite for someone who is not. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Grant a team access to a repository. POST /v2/repositories/{namespace}/{repository}/groups. Gives one organization team read, write or admin access to one repository. `write` lets every member of that team push images; `admin` lets them change the repository's settings and its other grants. The team is named by its numeric `group_id`, which the team read call returns -- not by its name. This applies to repositories owned by an ORGANIZATION. Measured 2026-09-17 against a personal namespace it answers `400 "user repositories do not have groups"`: a user's own repositories have no teams to grant, so there is nothing here to do for them. The 400 is about the repository's owner, not about the credential.

Update organization settings. PUT /v2/orgs/{name}/settings. Sets whether members of the organization may pull images from outside the allowed set, and which categories stay allowed when they may not. This changes what every member of the organization can pull, on every machine, as soon as it is saved: turning restriction on with both allowances off leaves members able to pull only the organization's own images. A PUT, so send the whole `restricted_images` document rather than one field of it. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Replace a team's details. PUT /v2/orgs/{org_name}/groups/{group_name}. Replaces the team's name and description. `name` is REQUIRED, so a call meaning only to change the description must send the existing name back or it will be rejected -- use the partial update instead when that is the intent. Renaming a team changes the name every other call addresses it by. Membership and repository grants are unaffected. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.

Change a member's organization role. PUT /v2/orgs/{org_name}/members/{username}. Sets one member's role in the organization. `owner` is full administrative control, including billing, membership and the ability to remove other owners -- granting it is the largest privilege change this integration can make, and demoting the last owner can leave the organization unadministrable. A custom role is named by its identifier, not by its display label or uuid. CREDENTIAL FLAVOUR, and it decides whether this call can work at all: measured 2026-09-17, a Hub JWT minted from a PERSONAL access token is answered `403 "token issued from personal access token is not allowed"` here -- identically on a real organization and on the connection's own namespace, while no credential at all answers 401 on the same route. So the 403 is about the token's FLAVOUR, not about permissions: retrying it, or minting a personal token with wider access, cannot clear it. Reconnect with an ORGANIZATION access token (Docker Home -> the organization -> Identity & auth -> Access tokens), which Docker issues on a Team or Business subscription to an account with Owner permission.