Registry

Endpoint reference for the package registries the platform serves: OCI container images, npm, PyPI, Go modules, and generic binary artifacts. Each protocol is a standards-compatible front door over one shared, repository-scoped artifact store, so the credentials, visibility rules, scopes, errors, and rate limits are common to all of them. This page documents what they share; the per-protocol pages document the paths a client uses to pull and publish.

Per-protocol pages:

• oci.md — OCI / Docker container images over the Distribution Spec /v2 API.
• npm.md — npm packages.
• pypi.md — Python packages over the PEP 503 simple index.
• go.md — Go modules over the GOPROXY protocol.
• generic.md — Arbitrary binary artifacts.

Base paths

Every artifact belongs to a repository, addressed by {owner}/{repo}. The registries are served from the same host as the REST API (https://api.gitvetrix.com; see Hosts), but they are not under the /api/v1 prefix — each protocol mounts at the root path its client tooling expects, except the generic registry.

Protocol	Base path
OCI / Docker	/v2/
npm	/npm/{owner}/{repo}/
PyPI	/pypi/{owner}/{repo}/
Go module	/go/{owner}/{repo}/
Generic	/api/v1/repos/{owner}/{repo}/packages/generic/

The OCI repository name is embedded in the path as {owner}/{repo}[/{image}]: alice/app addresses the repository app owned by alice, and an optional third segment (alice/app/web) names an image within that repository. When the image segment is omitted it defaults to the repository name.

Authentication

The registry endpoints accept the same bearer credentials as the rest of the API — see Authentication for how to obtain each one. How a credential is carried, and which kinds each protocol accepts, differs by client tooling:

• OCI / Docker uses token authentication. A client is challenged on /v2/, exchanges its credential for a short-lived, repository-scoped token at GET /v2/token, and replays that token as Authorization: Bearer. docker login presents the underlying credential (a session JWT, a personal access token, or a CI job token) as the HTTP Basic password in order to mint the token. See oci.md.
• npm, PyPI, Go module, and generic clients send the credential directly as Authorization: Bearer <token>, where <token> is a session or access-token JWT. These endpoints do not run the OCI token-exchange flow.

Anonymous (unauthenticated) access is allowed only for reads, and only where the repository's visibility permits it (below).

Read visibility

Repository visibility has three tiers — public, internal, and private — and it governs who may pull (read) artifacts:

Visibility	Who may pull
public	Anyone, including anonymous clients
internal	Any authenticated principal
private	The repository owner, instance admins, and collaborators whose role grants registry read

A pull denied because the caller may not read a private repository returns the same not-found response an unknown repository would, so the API never confirms a private repository's existence to an unauthorized caller. See 404, not 403, for private resources.

Push scopes

Publishing (push / upload) always requires an authenticated, authorized principal — anonymous writes are refused. Authorization combines the credential's scope with the caller's repository role:

Operation	OAuth2 scope	PAT scope	Repository role
Pull (read)	read:package	registry:read	any role that can read the repo
Push (publish)	write:package	registry:write	owner, admin, or a collaborator granted registry write

Only the generic and OCI/container registries expose a delete operation. npm, PyPI, and Go modules have no delete endpoint — packages published to those protocols cannot be removed through the registry API. Where delete is available (generic per-file delete, and the OCI /v2 manifest and blob routes), it also requires an authenticated, authorized principal:

Operation	OAuth2 scope	PAT scope	Repository role
Delete (generic, OCI/container)	write:package	—	owner, admin, or a collaborator granted registry delete

A personal access token narrows the credential down: a token without registry:read cannot pull even from a public repository, and registry:write implies pull. A CI job token may pull and push only the single repository it is bound to; it can never delete and never reach another repository. Deletion is granted only through a repository role that carries the registry-delete permission — it is not expressible as a token scope. See Scopes.

Errors

All registry endpoints report failures with the shared HTTP status-code conventions in errors.md, including the 404-not-403 rule for private repositories and the 503 returned when the registry feature is not configured on a deployment. The OCI /v2 API additionally wraps its errors in the Distribution Spec error envelope — see oci.md.

Rate limits

All registry traffic — across every protocol — is metered under the single registry rate-limit scope, separate from the REST api.* budgets so a burst of pulls or pushes cannot exhaust a caller's API allowance. A throttled request receives 429 Too Many Requests with the standard headers. See rate-limits.md.