Getting started with Red Hat APIs

Updated -

Using APIs for Red Hat services

APIs for Red Hat services can help you more effectively keep track of and automate:
* Subscriptions and entitlements
* User accounts and permissions


Red Hat APIs use OAuth 2.0 for authorization. To obtain a token and access the APIs, you will need the following pieces of information:

  • Offline token generated on the API Tokens page (User needs to have the View/Renew Subscription Information permission)
  • Client ID = rhsm-api
  • Token URL =
  • Installed jq to process JSON objects:
    • jq is a command-line JSON processor that can be installed using the yum command: sudo yum install jq

Generating a new offline token

An offline token never expires as long as it is used at least once every 30 days and is used to create access tokens. It works as a password and allows you to continue being able to authenticate your account without having to create new refresh tokens.

Warning: Please use password management that is consistent with networking best practices. It is never safe to store any passwords or credentials in plaintext. Treat your offline token with the same security measures that you would a password to protect it against unauthorized use.

To generate an offline token, visit the API Tokens page and click the Generate Token button.

Generating an access token

Once you have created the offline token, you can use that token to create a new refresh token, which includes an access token that is valid for five minutes. Access tokens are passed in the header to authenticate your Customer Portal user.

Warning: Please use password management that is consistent with networking best practices. It is never safe to store any passwords or credentials in plaintext.

Set the offline token value (in this example, we set it in plaintext and shorten the token value for clarity)
# offline_token='eyJhbGciOiJSUzI1NiIsInR5cCIgOiA'

# curl -d grant_type=refresh_token -d client_id=rhsm-api -d refresh_token=$offline_token

You should see an output similar to the below where access_token is what will be used as authorization token:


The access_token is what needs to be set/used as authorization token to perform the API call.

# token=$(curl -d grant_type=refresh_token -d client_id=rhsm-api -d refresh_token=$offline_token | jq --raw-output .access_token)

Perform an API call with the token

Example API call to list 100 systems:

# curl -H "Authorization: Bearer $token"  ""

Optional CLI tooling support

Install a JSON formatting tool, such as jq or optionally, json_reformat, to receive more structured returns of your API calls.

  • json_reformat is a command-line JSON formatter that comes standard on Red Hat Enterprise Linux.

Developers familiar with standard OIDC libraries that supports OAuth 2.0 can use those libraries to build authorization to the Red Hat Subscription Management APIs into scripts and applications.

An option for testing APIs, or for users who access APIs less frequently, is to use a REST client. As long as your REST client supports OAuth 2.0 or custom form submission, you can use that client to access the APIs. Some examples of popular REST clients include Postman, Advanced REST Client, and Restlet.

Accessing available Red Hat APIs

Red Hat provides a Swagger file to describe the specifications. The Swagger specification includes information about the API endpoints available, input parameters, expected output, and possible error responses. The swagger file can be imported into REST clients like Postman or RESTlet to automatically build a library of API calls. The Red Hat API Swagger documentation can be found on the Red Hat API Tokens and Swagger documentation page linked at the bottom of this article

Contact Red Hat

If you run into problems and require support, please open a support case.

Resources for downloads and Swagger documentation


  1. Obtain offline_token from

  2. Set the offline token:

# offline_token='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
* Verify it's set:

        # echo $offline_token
  1. Get the access token

    # curl -d grant_type=refresh_token -d client_id=rhsm-api -d refresh_token=$offline_token
  2. Grab the access token with the function we created before

     # token=$(curl -d grant_type=refresh_token -d client_id=rhsm-api -d refresh_token=$offline_token | jq --raw-output .access_token)
    • Verify the access_token is set

      # echo $token
  3. Perform an API call:

    # curl -H "Authorization: Bearer $token"  ""


The API only appears to support GET requests at this point, is that correct? Are there plans to allow changes via the API?

Hi Erinn! Yes, throughout the Tech Preview, we will be publishing additional endpoints for actions like attaching or removing entitlements from Systems, creating and managing Subscriptions on Subscription Allocations and Activation Keys, and many of the other functions you are accustomed to.

The API shows there are POSTs and DELETEs - are these functional now? - I seem to get a 302 response (redirect) when doing DELETE /systems/{uuid}

Yes, the POSTs, PUTs, and DELETEs that are listed in the swagger spec are all functional. As before, if you could submit a support case with steps, that would be great. I will also follow-up for more information. Thanks!

this was my mistake. I had not correctly addressed the endpoint.

from the swagger json

  "host": "",
  "basePath": "/management/v1",

So all urls are

and then tack on what ever you want to use in the swagger docs.

using python request module , it seems it is only returning response in html. Do you have example of what the request should look like ? This is what I have . r = requests.get(url, headers={"Content-Type": "application/json","Authorization":"Bearer %s " %(auth_token) })

Hi Mahesh.

The request should return JSON not the HTML. Try to load the json as below and check if you get any error.


Hello, When I request a list of systems by using the api, the list is limited to 100 even if I use the "?limit=500" parameter, did somebody notice the same ( or the syntax is not correct in the Swagger ) ? Exemple : curl -s -H "Authorization: Bearer $BEARER" -H "Content-Type: application/json" -X GET

The syntax is correct, though the description states, "The default and max number of results in a response are 100." We are always looking to tune the performance of these calls and may increase the max in the future.

Ok, Thanks.

We can obtain some information for a system ( Errata, Package, available pool ) but not the subscribed entitlement name, do you think it will be possible in the future ?


Adding an offset parameter (so: limit=100&offset=100) works.

Seeing -- {"error":"not_allowed","error_description":"Offline tokens not allowed for the user or client"}%

Getting the same error

Hi, did you convert the offline token to accesstoken and used that one to use the API? To test my theory before asking you this question, I tried to use the API with the offline token, but getting a different error (Authentication required). Ivan.

This assumes that only a web interface will be used. I would like to link a C library into a compiled application for the purpose of verifying the platform is running on is licensed by Red Hat. Has a current subscription. The correct level of subscription. So the customer can be informed of there liability, non-compliance and security situation. C or C++ (gcc) would be great.

Can't authenticate at all.

< HTTP/1.1 401 Unauthorized
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Content-Length: 24
< Date: Mon, 16 Sep 2019 15:45:31 GMT
< Connection: keep-alive
< Set-Cookie: ff5bc2a9348f7bd5a92b54af186b4a28=b305a95e900aac4ffc1758b7c58eb516; path=/; HttpOnly; Secure

Neither of these work

curl -v -H "Authorization: Bearer $TOKEN" \
    -X GET \
curl -v -X GET \
    -H "accept: application/json" \
    -H "Authorization: Bearer $TOKEN" \


Could you please open a new support case describing the steps you did and at which point you have the failure.




My bad on this.

  1. create offline token

  2. create online token from offline token in step #1

  3. authenticate with online token from step #2 and get API data

missed out step #2 doh!

Great thanks for the feedback, based on that I've added a new section "Troubleshooting" which contains the same steps as I provided in the case.

awesome, thanks again.

What if an advisory (example: RHBA-2019:2824) contains only container images and no RPM packages? How can I obtain the list of included container images? Obviously, call returns an empty body.

The list of container images is currently included in the details of the advisory (, but not in an easily-readable format. Providing a proper list of container images for an advisory in both the Customer Portal and in the RHSM API is high on our roadmap for early-to-mid 2020. I will follow up with you, Dominik, for some additional information. Thank you!

Yes, awesome! I now have the ability to crosscheck the Red Hat systems with our CMDB.

Hi, the API has a call for getting a specific system based on UUID. Where can I retreive that value from my system?

Hi Ivan! You can find the UUID of the system using $ subscription-manager identity

It is also available in the response from the /v1/systems endpoint.

Hi, we have separated subscriptions into different activation keys for 2 customer groups. An API to get my activation keys with their attached subscriptions as a subsdocument would be very helpful.

Hello again, Ivan! Mapping systems back to the activation key used to register them is something on our roadmap, but I don't have a target for it yet. Opening a support case for this RFE is a great way for us to track and communicate with you when we are closer to delivery.

Is it possible to get all registered systems of a specific activation key? Would be very useful.

Mapping systems back to the activation key used to register them is something on our roadmap, but I don't have a target for it yet. Opening a support case for this RFE is a great way for us to track and communicate with you when we are closer to delivery.

Is there an API allowing to create an Activation Key ?

There are no RHSM API endpoints for Activation Keys, but that is on our roadmap for 2020. I will follow-up with you via email with some follow-up questions. Thanks!

The link to the survey does not seem to be working. In any case, I'd love to see the ability to set the version of Satellite the allocation is for. It seems to default to 6.5, but we are on 6.6 and I know 6.7 isn't too far away.

I also found some issues with the swagger file, but I will open a ticket about those.

Hello, thanks for the article.

I have two suggestions: RHEL comes with a tool for processing JSON files "jq". It can be used instead of the very hard to read "jsonValue" function. The result is very similar. This is the version from this article:

token=`curl -d grant_type=refresh_token -d client_id=rhsm-api -d refresh_token=$offline_token | jsonValue access_token`

And this would be the equivalent:

token=`curl -d grant_type=refresh_token -d client_id=rhsm-api -d refresh_token=$offline_token | jq --raw-output .access_token`

Second, I'd use $() over `` for readability.

I think these could make the tutorial easier to read.

Can we access downloads (like RHEL9 iso and it's shasum) via the API ?