Skip to main content


Configure a bot to call runops API and automate things on behalf of your team.


Some companies commonly have some repetitive routines that needs to be performed. Even though a user can do that manually, sometimes it is more effective to automate things using a bot. Runops API, that handle requests from our many interface (slack, CLI, portal) can be accessed directly by a machine, and do the same things a user would do. This is a m2m (machine-to-machine) flow.

Generate a client id and client secret#

Ask someone from runops to provide your company a client-id and a client-secret.


Those are super secret, and in the wrong hands, can cause some damage (i.e. run tasks on organisation behalf).

Get an authorization token#

The token is issued by our auth provider (auth0), and the initial request is done directly on their domain.

# request
curl --request POST \
--url \
--header 'Content-Type: application/json' \
--data '{
"client_id": "we will",
"client_secret": "give you",
"audience": "",
"grant_type": "client_credentials"
"access_token": "eyJhb...czVEV5WSJ9.eyJodHR...",
"scope": "read:client_grants",
"expires_in": 86400,
"token_type": "Bearer"

Except for the client_id and client_secret, all other parameters should be sent as per the example.

The response contains a JWT access_token, that is used on subsequent requests.

Requesting Runops API#

Token must be sent as Bearer xxx in the Authorization header of the request. In this example, a list targets using the token:

curl --request GET \
--url '' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer eyJhbG...eyJod....j12DOa...'

Important considerations#

  • A bot user will be created in your org, and used to perform all activities. ({your-org-domain})
  • For analytics purposes, all actions taken with this token will be assigned to the bot user
  • The bot user is subject to access control as any other user (using the groups flag)
  • The m2m credentials in the wrong hands can cause some harm