Project Quay API guide

The Project Quay application programming interface (API) provides a comprehensive, RESTful interface for managing and automating tasks within Project Quay. Designed around the OAuth 2.0 protocol, this API enables secure, fine-grained access to Project Quay resources, and allows administrators and users to perform such actions as creating repositories, managing images, setting permissions, and more.

Project Quay follows Semantic Versioning (SemVer) principles, ensuring predictable API stability across releases, such as:

Major releases: Introduce new capabilities. Might include breaking changes to API compatibility. For example, the API of Project Quay 2.0 differs from Project Quay 3.0.
Minor releases: Add new functionality in a backward-compatible manner. For example, a 3.y release adds functionality to the version 3. release.
Patch releases: Deliver bug fixes and improvements while preserving backward compatibility with minor releases, such as 3.y.z.

The following guide describes the Project Quay API in more detail, and provides details on the following topics:

OAuth 2 access tokens and how they compare to traditional API tokens and Project Quay’s robot tokens
Generating an OAuth 2 access token
Best practices for token management
OAuth 2 access token capabilities
Using the Project Quay API
Project Quay API configuration examples

Introduction to Project Quay OAuth 2.0 tokens

The Project Quay OAuth 2 token system provides a secure, standards-based method for accessing Project Quay’s API and other relevant resources. The OAuth 2 token-based approach provides a secure method for handling authentication and authorization for complex environments. Compared to more traditional API tokens, Project Quay’s OAuth 2 token system offers the following enhancements:

Standards-based security, which adheres to the OAuth 2.0 protocol.
Revocable access by way of deleting the application in which the OAuth 2 token exists.
Fine-grained access control, which allows Project Quay administrators the ability to assign specific permissions to tokens.
Delegated access, which allows third-party applications and services to act on behalf of a user.
Future-proofing, which helps ensure that Project Quay remains compatible with other services, platforms, and integrations.

Project Quay primarily supports two types of tokens: OAuth 2 access tokens and robot account tokens. A third token type, an OCI referrers access token, that is required to list OCI referrers of a manifest under a repository, is also available when warranted.

The following chapters provide more details about each token type and how to generate each token type.

OAuth 2 access tokens

OAuth 2 access tokens (considered "API tokens" for Project Quay) enable user-authenticated access to the Project Quay API, suitable for applications that require user identity verification. These tokens are obtained through an OAuth 2 authorization process, where a Project Quay administrator generates a token on behalf of themselves or another user to access Project Quay API endpoints. OAuth 2 tokens authorize actions on API endpoints based on the scopes defined for the token.

Note

Although OAuth 2 tokens authorize actions on API endpoints based on the scopes defined for the token, access to the resources themselves is governed by Project Quay’s role-based access control (RBAC) mechanisms. Actions can be created on a resource, for example, a repository, provided that you have the proper role (Admin or Creator) to do so for that namespace. This is true even if the API token was granted the repo:admin scope.

OAuth 2 access tokens can only be created by using the Project Quay UI; there is no way to create an OAuth 2 access token by using the CLI. When creating an OAuth 2 token, the following options can be selected for a token holder:

Administer Organization. When selected, allows the user to be able to administer organizations, including creating robots, creating teams, adjusting team membership, and changing billing settings.
Administer Repositories. When selected, provides the user administrator access to all repositories to which the granting user has access.
Create Repositories. When selected, provides the user the ability to create repositories in any namespaces that the granting user is allowed to create repositories.
View all visible repositories. When selected, provides the user the ability to view and pull all repositories visible to the granting user.
Read/Write to any accessible repositories. When selected, provides the user the ability to view, push and pull to all repositories to which the granting user has write access.
Super User Access. When selected, provides the user the ability to administer your installation including managing users, managing organizations and other features found in the superuser panel.
Administer User When selected, provides the user the ability to administer your account including creating robots and granting them permissions to your repositories.
Read User Information. When selected, provides the user the ability to read user information such as username and email address.

Token distributors should be mindful of the permissions that they are granting when generating a token on behalf of a user, and should have absolute trust in a user before granting such permissions as Administer organization, Super User Access, and Administer User. Additionally, the access token is only revealed at the time of creation; they cannot be listed from the CLI, nor can they be found on the Project Quay UI. If an access token is lost or forgotten, a new token must be created; a token cannot be recovered.

OAuth 2 access tokens are passed as a Bearer token in the Authorization header of an API call and, as a result, are used to provide authentication and authorization to the defined API endpoint, such as an image tag, a repository, an organization, and so on.

The API is available from the /api/v1 endpoint of your Project Quay host. For example, https://<quay-server.example.com>/api/v1. It allows users to connect to endpoints through their browser to GET, POST, DELETE, and PUT Project Quay settings by enabling the Swagger UI. The API can be accessed by applications that make API calls and use OAuth tokens, and it sends and receives data as JSON.

With Project Quay, there is currently no way to rotate or to set an expiration time on an OAuth 2 access token, and the token lifespan is 10 years. Tokens can be deleted by deleting the applications in which they were created in the event that they are compromised, however, this deletes all tokens that were made within that specific application.

Note

In practice, Project Quay administrators could create a new OAuth application on the Applications page of their organization each time they wanted to create a new OAuth token for a user. This would ensure that a single application is not responsible for all OAuth tokens. As a result, in the event that a user’s token is compromised, the administrator would delete the application of the compromised token. This would help avoid disruption for other users whose tokens might be part of the same application.

The following sections shows you how to generate and reassign an OAuth 2 access token.

Creating an OAuth 2 access token

With Project Quay, you must create an OAuth 2 access token before you can access the API endpoints of your organization. OAuth 2 access token can only be generated by using the Project Quay UI; the CLI cannot be used to generate an OAuth 2 access token.

Use the following procedure to create an OAuth2 access token.

Prerequisites

You have logged in to Project Quay as an administrator.
You have created an OAuth 2 application.

Procedure

On the main page, select an Organization.
In the navigation pane, select Applications.
Click the name of your application, for example, Test application.
In the navigation pane, select Generate Token.
Check the boxes for the following options:
1. Administer Organization. When selected, allows the user to be able to administer organizations, including creating robots, creating teams, adjusting team membership, and changing billing settings.
2. Administer Repositories. When selected, provides the user administrator access to all repositories to which the granting user has access.
3. Create Repositories. When selected, provides the user the ability to create repositories in any namespaces that the granting user is allowed to create repositories.
4. View all visible repositories. When selected, provides the user the ability to view and pull all repositories visible to the granting user.
5. Read/Write to any accessible repositories. When selected, provides the user the ability to view, push and pull to all repositories to which the granting user has write access.
6. Super User Access. When selected, provides the user the ability to administer your installation including managing users, managing organizations and other features found in the superuser panel.
7. Administer User When selected, provides the user the ability to administer your account including creating robots and granting them permissions to your repositories.
8. Read User Information. When selected, provides the user the ability to read user information such as username and email address.
Click Generate Access Token. You are redirected to a new page.
Review the permissions that you are allowing, then click Authorize Application. Confirm your decision by clicking Authorize Application.
You are redirected to the Access Token page. Copy and save the access token.

Important

This is the only opportunity to copy and save the access token. It cannot be reobtained after leaving this page.

Reassigning an OAuth access token

Organization administrators can assign OAuth API tokens to be created by other user’s with specific permissions. This allows the audit logs to be reflected accurately when the token is used by a user that has no organization administrative permissions to create an OAuth API token.

Note	The following procedure only works on the current Project Quay UI. It is not currently implemented in the Project Quay v2 UI.

Prerequisites

You are logged in as a user with organization administrative privileges, which allows you to assign an OAuth API token.

Note	OAuth API tokens are used for authentication and not authorization. For example, the user that you are assigning the OAuth token to must have the `Admin` team role to use administrative API endpoints. For more information, see Managing access to repositories.

Procedure

Optional. If not already, update your Project Quay config.yaml file to include the FEATURE_ASSIGN_OAUTH_TOKEN: true field:
```
# ...
FEATURE_ASSIGN_OAUTH_TOKEN: true
# ...
```
Optional. Restart your Project Quay registry.
Log in to your Project Quay registry as an organization administrator.
Click the name of the organization in which you created the OAuth token for.
In the navigation pane, click Applications.
Click the proper application name.
In the navigation pane, click Generate Token.
Click Assign another user and enter the name of the user that will take over the OAuth token.

Check the boxes for the desired permissions that you want the new user to have. For example, if you only want the new user to be able to create repositories, click Create Repositories.

Important

Permission control is defined by the team role within an organization and must be configured regardless of the options selected here. For example, the user that you are assigning the OAuth token to must have the Admin team role to use administrative API endpoints.

Solely checking the Super User Access box does not actually grant the user this permission. Superusers must be configured via the config.yaml file and the box must be checked here.

Click Assign token. A popup box appears that confirms authorization with the following message and shows you the approved permissions:
```
This will prompt user <username> to generate a token with the following permissions:
repo:create
```
Click Assign token in the popup box. You are redirected to a new page that displays the following message:
```
Token assigned successfully
```

Verification

After reassigning an OAuth token, the assigned user must accept the token to receive the bearer token, which is required to use API endpoints. Request that the assigned user logs into the Project Quay registry.
After they have logged in, they must click their username under Users and Organizations.
In the navigation pane, they must click External Logins And Applications.
Under Authorized Applications, they must confirm the application by clicking Authorize Application. They are directed to a new page where they must reconfirm by clicking Authorize Application.
They are redirected to a new page that reveals their bearer token. They must save this bearer token, as it cannot be viewed again.

Deleting an OAuth 2 access token

Because OAuth 2 access tokens are created through the OAuth application, they cannot be rotated or renewed. In the event that a token is compromised, or you need to delete a token, you must deleted its associated application through the Project Quay UI.

Important

Deleting an application deletes all tokens that were made within that specific application. Use with caution.

Prerequisites

You have created an OAuth 2 access token.

Procedure

On the Project Quay UI, click the name of the organization hosting the application. Then, in the navigation pane, click Applications.
Click the application name, for example, Test application.
In the navigation pane, click Delete Application. You are redirected to a new page. Click Delete application and confirm your decision.

Robot account tokens

Robot account tokens are password-type credentials used to access a Project Quay registry via normal Docker v2 endpoints; these are defined as tokens on the UI because the password itself is encrypted.

Robot account tokens are persistent tokens designed for automation and continuous integration workflows. By default, Project Quay’s robot account tokens do not expire and do not require user interaction, which makes robot accounts ideal for non-interactive use cases.

Robot account tokens are automatically generated at the time of a robot’s creation and are non-user specific; that is, they are connected to the user and organization namespace where where they are created. for example, a robot named project_tools+<robot_name> is associated with the project_tools namespace.

Robot account tokens provide access without needing a user’s personal credentials. How the robot account is configured, for example, with one of READ, WRITE, or ADMIN permissions, ultimately defines the actions that the robot account can take.

Because robot account tokens are persistent and do not expire by default, they are ideal for automated workflows that require consistent access to Project Quay without manual renewal. Despite this, robot account tokens can be easily re-generated by using the the UI. They can also be regenerated by using the proper API endpoint via the CLI. To enhance the security of your Project Quay deployment, administrators should regularly refresh robot account tokens. Additionally, with the keyless authentication with robot accounts feature, robot account tokens can be exchanged for external OIDC tokens and leveraged so that they only last one hour, enhancing the security of your registry.

When a namespace gets deleted, or when the robot account is deleted itself, they are garbage collected when the collector is scheduled to run.

The following section shows you how to use the API to re-generate a robot account token for organization robots and user robots.

Regenerating a robot account token by using the Project Quay UI

Use the following procedure to regenerate a robot account token by using the Project Quay UI.

Prerequisites

You have logged into Project Quay.

Procedure

Click the name of an Organization.
In the navigation pane, click Robot accounts.
Click the name of your robot account, for example, testorg3+test.
Click Regenerate token in the popup box.

Regenerating a robot account token by using the Project Quay API

Use the following procedure to regenerate a robot account token using the Project Quay API.

Prerequisites

You have Created an OAuth access token.
You have set BROWSER_API_CALLS_XHR_ONLY: false in your config.yaml file.

Procedure

Enter the following command to regenerate a robot account token for an organization using the POST /api/v1/organization/{orgname}/robots/{robot_shortname}/regenerate endpoint:

$ curl -X POST \
  -H "Authorization: Bearer <bearer_token>" \
  "<quay-server.example.com>/api/v1/organization/<orgname>/robots/<robot_shortname>/regenerate"

Example output

{"name": "test-org+test", "created": "Fri, 10 May 2024 17:46:02 -0000", "last_accessed": null, "description": "", "token": "<example_secret>"}

Enter the following command to regenerate a robot account token for the current user with the POST /api/v1/user/robots/{robot_shortname}/regenerate endpoint:

$ curl -X POST \
  -H "Authorization: Bearer <bearer_token>" \
  "<quay-server.example.com>/api/v1/user/robots/<robot_shortname>/regenerate"

Example output

{"name": "quayadmin+test", "created": "Fri, 10 May 2024 14:12:11 -0000", "last_accessed": null, "description": "", "token": "<example_secret>"}

OCI referrers OAuth access token

In some cases, depending on the features that your Project Quay deployment is configured to use, you might need to leverage an OCI referrers OAuth access token. OCI referrers OAuth access tokens are used to list OCI referrers of a manifest under a repository, and uses a curl command to make a GET request to the Project Quay v2/auth endpoint.

These tokens are obtained via basic HTTP authentication, wherein the user provides a username and password encoded in Base64 to authenticate directly with the v2/auth API endpoint. As such, they are based directly on the user’s credentials aod do not follow the same detailed authorization flow as OAuth 2, but still allow a user to authorize API requests.

OCI referrers OAuth access tokens do not offer scope-based permissions and do not expire. They are solely used to list OCI referrers of a manifest under a repository.

Additional resource

Attaching referrers to an image tag

Creating an OCI referrers OAuth access token

This OCI referrers OAuth access token is used to list OCI referrers of a manifest under a repository.

Procedure

Update your config.yaml file to include the FEATURE_REFERRERS_API: true field. For example:
```
# ...
FEATURE_REFERRERS_API: true
# ...
```
Enter the following command to Base64 encode your credentials:
```
$ echo -n '<username>:<password>' | base64
```
Example output
```
abcdeWFkbWluOjE5ODlraWROZXQxIQ==
```

Enter the following command to use the base64 encoded string and modify the URL endpoint to your Project Quay server:

$ curl --location '<quay-server.example.com>/v2/auth?service=<quay-server.example.com>&scope=repository:quay/listocireferrs:pull,push' --header 'Authorization: Basic <base64_username:password_encode_token>' -k | jq

Example output

{
  "token": "<example_secret>
}

Enabling and using the Project Quay API

By leveraging the Project Quay API, you can streamline container registry management, automate tasks, and integrate Project Quay’s functionalities into your existing workflow. This can improve efficiency, offer enhanced flexibility (by way of repository management, user management, user permissions, image management, and so on), increase the stability of your organization, repository, or overall deployment, and more.

The following sections explain how to enable and use the Project Quay API.

Configuring Project Quay to accept API calls

Prior to using the Project Quay API, you must disable BROWSER_API_CALLS_XHR_ONLY in your config.yaml file. This allows you to avoid such errors as API calls must be invoked with an X-Requested-With header if called from a browser.

Procedure

In your Project Quay config.yaml file, set BROWSER_API_CALLS_XHR_ONLY to false. For example:
```
# ...
BROWSER_API_CALLS_XHR_ONLY: false
# ...
```
Restart your Project Quay deployment.

Using the Project Quay API

After you have created an application and generated an OAuth 2 access token with the desired settings, you can pass in the access token to GET, PUT, POST, or DELETE settings by using the API from the CLI. Generally, a Project Quay API command looks similar to the following example:

$ curl -X GET -H "Authorization: Bearer <your_access_token>" (1)
    https://<quay-server.example.com>/api/v1/<example>/<endpoint>/ (2)

The OAuth 2 access token that was generated through the Project Quay UI.
The URL of your Project Quay deployment and the desired API endpoint.

All Project Quay APIs are documented in the Application Programming Interface (API) chapter. Understanding how they are documented is crucial to successful invocation. Take, for example, the following entry for the createAppToken API endpoint:

*createAppToken* (1)
Create a new app specific token for user. (2)

*POST /api/v1/user/apptoken* (3)

**Authorizations: **oauth2_implicit (**user:admin**) (4)

 Request body schema (application/json)

*Path parameters* (5)

Name: **title**
Description: Friendly name to help identify the token.
Schema: string

*Responses* (6)

|HTTP Code|Description             |Schema
|201      |Successful creation     |
|400      |Bad Request             |&lt;&lt;_apierror,ApiError&gt;&gt;
|401      |Session required        |&lt;&lt;_apierror,ApiError&gt;&gt;
|403      |Unauthorized access     |&lt;&lt;_apierror,ApiError&gt;&gt;
|404      |Not found               |&lt;&lt;_apierror,ApiError&gt;&gt;
|===

The name of the API endpoint.
A brief description of the API endpoint.
The API endpoint used for invocation.
The authorizations required to use the API endpoint.
The available paths to be used with the API endpoint. In this example, title is the only path to be used with the POST /api/v1/user/apptoken endpoint.
The API responses for this endpoint.

In order to use an API endpoint, you pass in your access token and then include the appropriate fields depending on your needs. The following procedure shows you how to use the POST /api/v1/user/apptoken endpoint.

Prerequisites

You have access to the Project Quay API, which entails having already created an OAuth 2 access token.
You have set BROWSER_API_CALLS_XHR_ONLY: false in your config.yaml file.

Procedure

Create a user application by entering the POST /api/v1/user/apptoken API call:

$ curl -X POST \
  -H "Authorization: Bearer <access_token>" (1)
  -H "Content-Type: application/json" \
  -d '{
    "title": "MyAppToken" (2)
  }' \
  "http://quay-server.example.com/api/v1/user/apptoken" (3)

The Oauth access token.
The name of your application token.

The URL of your Project Quay deployment appended with the /api/v1/user/apptoken endpoint.

Example output

{"token": {"uuid": "6b5aa827-cee5-4fbe-a434-4b7b8a245ca7", "title": "MyAppToken", "last_accessed": null, "created": "Wed, 08 Jan 2025 19:32:48 -0000", "expiration": null, "token_code": "K2YQB1YO0ABYV5OBUYOMF9MCUABN12Y608Q9RHFXBI8K7IE8TYCI4WEEXSVH1AXWKZCKGUVA57PSA8N48PWED9F27PXATFUVUD9QDNCE9GOT9Q8ACYPIN0HL"}}

Verification

On the Project Quay UI, click your username in the navigation pane → Account Settings. The name of your application appears under the Docker CLI and other Application Tokens heading. For example:

Automating Project Quay processes by using the API

With the API, Project Quay administrators and users with access to the API can automate repetitive tasks such as repository management or image pruning. The following example shows you how you might use a Python script and a cron job to to automate image pruning.

Prerequisites

You have access to the Project Quay API, which entails having already created an OAuth 2 access token.
You have set BROWSER_API_CALLS_XHR_ONLY: false in your config.yaml file.
You have installed the Python requests library using.
You have enabled cron jobs on your machine.

Procedure

Create a Python script that executes an API command. The following example is used to prune images using the DELETE /api/v1/repository/{repository}/tag/{tag} API endpoint.

example.py file

import requests (1)

# Hard-coded values
API_BASE_URL = "http://<quay-server.example.com>/api/v1" (2)
ACCESS_TOKEN = "<access_token>" (3)
NAMESPACE = "<namespace_name>" (4)
REPO_NAME = "<repository_name>" (5)
TAG = "<tag_name>" (6)

def delete_image_tag():
    # Construct the full API URL for deleting the tag
    url = f"{API_BASE_URL}/repository/{NAMESPACE}/{REPO_NAME}/tag/{TAG}"
    headers = {
        "Authorization": f"Bearer {ACCESS_TOKEN}",
        "Content-Type": "application/json"
    }

    # Send the DELETE request to the API
    response = requests.delete(url, headers=headers)

    # Check the response and print appropriate messages
    if response.status_code == 200:
        print("Tag deleted successfully")
    else:
        print("Failed to delete tag:", response.json())

# Execute the function
delete_image_tag()

Includes the import library in your Python code.
The URL of your registry appended with /api/v1.
Your OAuth 2 access token.
The namespace that holds the image tag.
The repository that holds the image tag.
The tag name of the image.

Save the script as prune_images.py.
Create a cron job that automatically runs the script:
1. Open the crontab editor by running the following command:
  $ crontab -e
2. In the editor, add the cron job for running the script. The following example runs the script every minute:
  * * * * * sudo python /path/to/prune_images.py >> /var/log/prune_images.log 2>&1

Project Quay API examples

The remainder of this chapter provides Project Quay API examples for the features in which they are available.

Managing a user application by using the API

Project Quay users can create, list information about, and delete a user application that can be used as an alternative to using your password for Docker, Podman, or other service providers. User application tokens work like your username and password, but are encrypted and do not provide any information to third parties regarding who is accessing Project Quay.

Note	After creation via the CLI, the user application token is listed under User Settings of the Project Quay UI. Note that this differs from an application token that is created under user settings, and should be considered a different application entirely.

Use the following procedure to create a user application token.

Prerequisites

You have created an OAuth 2 access token.

Procedure

Create a user application by entering the POST /api/v1/user/apptoken API call:

$ curl -X POST \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "MyAppToken"
  }' \
  "http://quay-server.example.com/api/v1/user/apptoken"

Example output

{"token": {"uuid": "6b5aa827-cee5-4fbe-a434-4b7b8a245ca7", "title": "MyAppToken", "last_accessed": null, "created": "Wed, 08 Jan 2025 19:32:48 -0000", "expiration": null, "token_code": "K2YQB1YO0ABYV5OBUYOMF9MCUABN12Y608Q9RHFXBI8K7IE8TYCI4WEEXSVH1AXWKZCKGUVA57PSA8N48PWED9F27PXATFUVUD9QDNCE9GOT9Q8ACYPIN0HL"}}

You can obtain information about your application, including when the application expires, by using the GET /api/v1/user/apptoken command. For example:

$ curl -X GET \
  -H "Authorization: Bearer <access_token>" \
  "http://quay-server.example.com/api/v1/user/apptoken"

{"tokens": [{"uuid": "6b5aa827-cee5-4fbe-a434-4b7b8a245ca7", "title": "MyAppToken", "last_accessed": null, "created": "Wed, 08 Jan 2025 19:32:48 -0000", "expiration": null}], "only_expiring": null}

You can obtain information about a specific user application by entering the GET /api/v1/user/apptoken/{token_uuid} command:

$ curl -X GET \
  -H "Authorization: Bearer <access_token>" \
  "http://quay-server.example.com/api/v1/user/apptoken/<token_uuid>"

Example output

{"token": {"uuid": "6b5aa827-cee5-4fbe-a434-4b7b8a245ca7", "title": "MyAppToken", "last_accessed": null, "created": "Wed, 08 Jan 2025 19:32:48 -0000", "expiration": null, "token_code": "K2YQB1YO0ABYV5OBUYOMF9MCUABN12Y608Q9RHFXBI8K7IE8TYCI4WEEXSVH1AXWKZCKGUVA57PSA8N48PWED9F27PXATFUVUD9QDNCE9GOT9Q8ACYPIN0HL"}}

You can delete or revoke a user application token by using the DELETE /api/v1/user/apptoken/{token_uuid} endpoint:
```
$ curl -X DELETE \
  -H "Authorization: Bearer <access_token>" \
  "http://quay-server.example.com/api/v1/user/apptoken/<token_uuid>"
```
This command does not return output in the CLI. You can return a list of tokens by entering one of the aforementioned commands.

Discovering Project Quay API endpoints

Project Quay API endpoints are discoverable by using the API.

Use the following procedure to discover available API endpoints.

Prerequisites

You have created an OAuth 2 access token.

Procedure

Enter the following GET /api/v1/discovery command to list all of the API endpoints available in the swagger API format:

$ curl -X GET "https://<quay-server.example.com>/api/v1/discovery?query=true" \
    -H "Authorization: Bearer <access_token>"

Example output

---
: "Manage the tags of a repository."}, {"name": "team", "description": "Create, list and manage an organization's teams."}, {"name": "trigger", "description": "Create, list and manage build triggers."}, {"name": "user", "description": "Manage the current user."}, {"name": "userfiles", "description": ""}]}
---

Obtaining Project Quay API error details

Project Quay API error details are discoverable by using the API.

Use the following procedure to discover error details.

Prerequisites

You have created an OAuth 2 access token.

Procedure

You can obtain error details of the API by entering the GET /api/v1/error/{error_type} endpoint. Note that you must include one of the following error codes:

HTTP Code	Description	Schema
200	Successful invocation	ApiErrorDescription
400	Bad Request	ApiError
401	Session required	ApiError
403	Unauthorized access	ApiError
404	Not found	ApiError

HTTP Code

Description

Schema

200

Successful invocation

ApiErrorDescription

400

Bad Request

Project Quay API guide

Introduction to Project Quay OAuth 2.0 tokens

OAuth 2 access tokens

Creating an OAuth 2 access token

Reassigning an OAuth access token

Deleting an OAuth 2 access token

Robot account tokens

Regenerating a robot account token by using the Project Quay UI

Regenerating a robot account token by using the Project Quay API

OCI referrers OAuth access token

Additional resource

Creating an OCI referrers OAuth access token

Enabling and using the Project Quay API

Configuring Project Quay to accept API calls

Using the Project Quay API

Automating Project Quay processes by using the API

Project Quay API examples

Managing a user application by using the API

Discovering Project Quay API endpoints

Obtaining Project Quay API error details

Global messages

Viewing usage logs by using the API

Viewing aggregated logs

Viewing detailed logs

Exporting logs by using the API

Adding and managing labels by using the API

Using the API to mirror a repository

Establishing quota with the Project Quay API

Managing organization quota with the Project Quay API

Setting quota limits for an organization with the Project Quay API

Obtaining quota limits for the user with the Project Quay API

Establishing quota with the Project Quay API

Creating an organization by using the Project Quay API

Deleting an organization by using the Project Quay API

Retrieving organization member information by using the API

Creating an organization application by using the Project Quay API

Configuring a proxy cache for an organization by using the Project Quay API

Managing team members and repository permissions by using the API

Project Quay Application Programming Interface (API)

Authorization

Scopes

appspecifictokens

createAppToken

POST /api/v1/user/apptoken

Request body schema (application/json)

Responses

Example command

listAppTokens

GET /api/v1/user/apptoken

Query parameters

Responses

Example command

getAppToken

GET /api/v1/user/apptoken/{token_uuid}

Path parameters

Responses

Example command

revokeAppToken

DELETE /api/v1/user/apptoken/{token_uuid}

Path parameters

Responses

Example command

build

getRepoBuildStatus

GET /api/v1/repository/{repository}/build/{build_uuid}/status

Path parameters

Responses

getRepoBuildLogs

GET /api/v1/repository/{repository}/build/{build_uuid}/logs

Path parameters

Responses

getRepoBuild

GET /api/v1/repository/{repository}/build/{build_uuid}

Path parameters

Responses

cancelRepoBuild

DELETE /api/v1/repository/{repository}/build/{build_uuid}

Path parameters

Responses

requestRepoBuild