Alerts: rules and matches.

Alert rules watch your intelligence for the conditions you care about, and the API lets you read those rules and the events they matched. That is enough to route Liberty91 alerting into whatever already runs your operations: a SOAR, a ticketing queue, or a chat channel.

Both endpoints require the alerts.read scope. Rules themselves are created and managed in the platform (see Set up automatic alerting).

List alert rules

GET /api/v1/alerts/ returns your rules:

curl "https://api.liberty91.com/api/v1/alerts/" \
  -H "X-API-Key: $LIBERTY91_API_KEY"

{
  "results": [
    {
      "id": "9a8b7c6d-...",
      "name": "Infostealer reporting, EMEA financials",
      "is_active": true
    }
  ]
}

Get a rule's matches

GET /api/v1/alerts/{id}/matches/ returns the event instances the rule has matched, cursor-paginated like every other list:

curl "https://api.liberty91.com/api/v1/alerts/9a8b7c6d-.../matches/" \
  -H "X-API-Key: $LIBERTY91_API_KEY"

Matches are ordinary event instances with the same shape as the events list, so the id of any match feeds straight into the event detail endpoint or into report generation.

A simple forwarding loop

Rule and match reads cost 1 credit each, so even a few rules polled every five minutes stays comfortably cheap.

Frequently asked questions

Can I create alert rules through the API?

Not in v1. Rules are created and managed in the platform; the API exposes them read-only, along with the events each rule matched. The v1 contract is additive, so write support can arrive without breaking existing integrations.

How do I get alert matches into my SOAR or ticketing system?

List your rules once, then poll each rule's matches/ endpoint on a schedule and forward anything new. Matches are event instances, so they carry the same IDs you use everywhere else in the API.