Skip to main content

​
Read and triage matches

Every time a rule runs and finds new hits, it records a match — an incident, in the dashboard. A match is a header (which rule, which source, the time window, a status) plus a page of hit rows. This is the payoff of monitoring: you read incidents instead of re-running searches.

​
List incidents

alert_system_alert_get_alert_match_list returns your matches, newest first:
Filter with from_date / to_date (YYYY-MM-DD), alert_rule_id, service_id, status, and show_excluded; paginate with page / page_size (max 100). It returns {count, next, previous, results}, where each result is the incident header: id, alert_rule, service, args (the asset snapshot at run time), from_time / to_time (the run window), creation_date, status, total_results_count, and excluded_results_count.

​
Open one and read the hits

The header alone doesn’t carry the hits. Get the metadata with alert_system_alert_get_alert_match_detail, and the actual rows with alert_system_alert_get_alert_match_detail_results:
It returns {count, next, previous, results}. Each result wraps one hit:
The data object is the source’s own hit row, stored verbatim — monitoring doesn’t reshape it. So a match’s hits look exactly like that source’s search results: a Telegram match carries Telegram messages, a Phishing match carries phishing records, a Filtered Credentials match carries credential rows, and so on. To learn a match’s shape, read the page for its source. Refine the rows with:
  • show_excluded — false (default) hides excluded rows; true includes them.
  • filters — a JSON object of source-specific filters (e.g. {"fileExtension": "pdf"}), validated against the service’s filterable_fields.
  • ordering — a field from the service’s sortable_fields, prefixed with - for descending.

​
Triage

A match carries one of four statuses — Open (default), In Progress, False Positive, Resolved — set with alert_system_alert_update_alert_match_status:
The dashboard simplifies these four to **Not Seen** (`Open`) and **Seen** (`Resolved`) — opening an incident marks it Seen automatically. The API accepts and returns all four values.

​
Export

alert_system_alert_download_alert_match_detail returns the hits as a file. file_type is required — json, csv, or excel — and the same show_excluded, filters, and ordering options apply:
A match with no results (after filtering) returns 404. For CSV, the column headers come from the first row’s keys, so a source whose rows vary in shape is cleaner as json. For the broader difference between source-specific downloads, the general export service, and original leak-file downloads, see Downloads and exports.

​
Delete

alert_system_alert_delete_alert_match removes an incident and its rows — a 204 on success. Unlike a rule, this is a hard delete.

​
A note on excluded rows

A hit is flagged is_excluded when it matches one of the rule’s exclusions at the moment it’s recorded — exclusions flag, they don’t drop. excluded_results_count counts the flagged rows in a match; total_results_count counts all of them. By default excluded rows are hidden everywhere (and a match whose results are entirely excluded drops out of the list); pass show_excluded=true to see them.