Common API tasks

The examples below cover the operations most people automate first. They use the environment variables set in the authentication article.

Listing endpoints for a client is usually the starting point of any script, because most subsequent calls need an endpoint identifier.

curl "$AEGISONE_HOST/api/agents?client_id=<client_id>" \
  -H "Authorization: Bearer $AEGISONE_TOKEN"

Dispatching a patch scan across a set of endpoints is the second most common. Note the deliberate pause between calls — firing hundreds of dispatches as fast as your loop can issue them is unkind to both the platform and the estate.

for id in $(cat endpoint_ids.txt); do
  curl -sS -X POST "$AEGISONE_HOST/api/agent/$id/patch/scan" \
    -H "Authorization: Bearer $AEGISONE_TOKEN" \
    -o /dev/null -w "%{http_code} $id\n"
  sleep 1
done

Reading compliance findings, or reconciliation findings, is how most reporting integrations are built — pull the findings, filter them on your side, and raise what matters into your ticketing system.

curl "$AEGISONE_HOST/api/compliance/findings?client_id=<client_id>" \
  -H "Authorization: Bearer $AEGISONE_TOKEN"

curl "$AEGISONE_HOST/api/reconciliation/findings?client_id=<client_id>" \
  -H "Authorization: Bearer $AEGISONE_TOKEN"

Generating an export programmatically is useful when a report needs to arrive somewhere on a schedule. The schedule lives on your side — the platform does not run one for you.

curl -X POST "$AEGISONE_HOST/api/exports/pdf" \
  -H "Authorization: Bearer $AEGISONE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"report":"<report_key>","client_id":"<client_id>"}' \
  -o report.pdf

A small piece of advice that outlives any specific endpoint: log the request and the response status in your integration, and keep those logs. When an integration that has run untouched for a year starts behaving oddly, the log is the only thing that will tell you whether the change was on your side.