Chapter 1. Using the Red Hat Quay API

Red Hat Quay provides a full OAuth 2, RESTful API that:

  • Is available from endpoints of each Red Hat Quay instance from the URL https://<yourquayhost>/api/v1
  • Lets you connect to endpoints, via a browser, to get, delete, post, and put Red Hat Quay settings by enabling the Swagger UI
  • Can be accessed by applications that make API calls and use OAuth tokens
  • Sends and receives data as JSON

The following text describes how to access the Red Hat Quay API and use it to view and modify setting in your Red Hat Quay cluster. Appendix A lists and describes API endpoints.

1.1. Accessing the Red Hat Quay API from

If you don’t have your own Red Hat Quay cluster running yet, you can explore the Red Hat Quay API available from from your web browser:

The API Explorer that appears shows API endpoints. You will not see superuser API endpoints or endpoints for Red Hat Quay features that are not enabled on (such as Repository Mirroring).

From API Explorer, you can get, and sometimes change, information on:

  • Billing, subscriptions, and plans
  • Repository builds and build triggers
  • Error messages and global messages
  • Repository images, manifests, permissions, notifications, vulnerabilities, and image signing
  • Usage logs
  • Organizations, members and OAuth applications
  • User and robot accounts
  • and more…​

Select to open an endpoint to view the Model Schema for each part of the endpoint. Open an endpoint, enter any required parameters (such as a repository name or image), then select the Try it out! button to query or change settings associated with a endpoint.

1.2. Create OAuth access token

To create an OAuth access token so you can access the API for your organization:

  1. Log in to Red Hat Quay and select your Organization (or create a new one).
  2. Select the Applications icon from the left navigation.
  3. Select Create New Application and give the new application a name when prompted.
  4. Select the new application.
  5. Select Generate Token from the left navigation.
  6. Select the checkboxes to set the scope of the token and select Generate Access Token.
  7. Review the permissions you are allowing and select Authorize Application to approve it.
  8. Copy the newly generated token to use to access the API.

1.3. Accessing your Red Hat Quay API from a web browser

By enabling Swagger, you can access the API for your own Red Hat Quay instance through a web browser. This URL exposes the Red Hat Quay API explorer via the Swagger UI and this URL:


That way of accessing the API does not include superuser endpoints that are available on Red Hat Quay installations. Here is an example of accessing a Red Hat Quay API interface running on the local system by running the swagger-ui container image:

# export SERVER_HOSTNAME=<yourhostname>
# podman run -p 8888:8080 -e API_URL=https://$SERVER_HOSTNAME:8443/api/v1/discovery

With the swagger-ui container running, open your web browser to localhost port 8888 to view API endpoints via the swagger-ui container.

To avoid errors in the log such as "API calls must be invoked with an X-Requested-With header if called from a browser," add the following line to the config.yaml on all nodes in the cluster and restart Red Hat Quay:


1.4. Accessing the Red Hat Quay API from the command line

You can use the curl command to GET, PUT, POST, or DELETE settings via the API for your Red Hat Quay cluster. Replace <token> with the OAuth access token you created earlier to get or change settings in the following examples.

1.4.1. Get superuser information

$ curl -X GET -H "Authorization: Bearer <token_here>" \

1.4.2. Create a repository build via API

In order to build a repository from the specified input and tag the build with custom tags, users can use requestRepoBuild endpoint. It takes the following data:

"docker_tags": [
"pull_robot": "string",
"subdirectory": "string",
"archive_url": "string"

The archive_url parameter should point to a tar or zip archive that includes the Dockerfile and other required files for the build. The file_id parameter was apart of our older build system. It cannot be used anymore. If Dockerfile is in a sub-directory it needs to be specified as well.

The archive should be publicly accessible. OAuth app should have "Administer Organization" scope because only organization admins have access to the robots' account tokens. Otherwise, someone could get robot permissions by simply granting a build access to a robot (without having access themselves), and use it to grab the image contents. In case of errors, check the json block returned and ensure the archive location, pull robot, and other parameters are being passed correctly. Click "Download logs" on the top-right of the individual build’s page to check the logs for more verbose messaging.

1.4.3. Create an org robot

$ curl -X PUT{orgname}/robots/{robot shortname} \
   -H 'Authorization: Bearer <token>''

1.4.4. Trigger a build

$ curl -X POST \
   -H 'Authorization: Bearer <token>'

Python with requests

import requests
r ='', headers={'content-type': 'application/json', 'Authorization': 'Bearer <redacted>'}, data={[<request-body-contents>})

1.4.5. Create a private repository

$ curl -X POST \
   -d '{"namespace":"yournamespace","name":"reponame","description":"description of your repo","visibility":"private"}' -H 'Authorization: Bearer {token}'