Skip to main content
A competitor report has two layers: a summary row (counts, status, ids) returned in list views, and the full report_data attack/defend payload returned when you fetch a single report by id.

Report object

GET /api/public/competitor-monitoring/reports returns these fields per report (the heavy report_data blob is omitted from the list). GET .../reports/{reportID} returns the same fields plus search_params and report_data.

report_data

The body splits into a summary header, the atk and def account lists (each an array of account signals, ranked by distinct_reps, then comments, then interactions, then the latest touch), and a reps drill-down.

summary

atk / def (account signal)

Each entry in atk and def is one account the competitor touched. def accounts are those you own (matched to a CRM company or owner); atk accounts are everything else. Each targets entry:

reps

Per competitor rep, the interactions they made. Each interactions entry:

How accounts are ranked

Within atk and def, the account the most competitor reps touched comes first, because several of their people on one account is the strongest sign. Ties go to the account with more comments, then more interactions, then the most recent touch.

Example report

GET /api/public/competitor-monitoring/reports/{reportID}:

Report-ready webhook

If the competitor report’s webhook is on (see Update Delivery Config), Clustr POSTs a competitor_monitoring.report_ready event to your URL each time the report goes out. There is one report for the whole workspace, covering every competitor, so the payload lists the competitors and every account the report covers, uncapped. A workspace that splits its audiences into routes gets one POST per route, each carrying that route’s accounts. The report covers everything since the previous one (the last 14 days for the first), at most once per monitoring period, and only when a competitor’s people engaged someone at a company in that time. An account is a company: people whose company is not known are counted in people_no_company.
Each element of accounts: The request carries X-ClustR-Event: competitor_monitoring.report_ready and is not signed: the report’s delivery settings have no secret. It goes through the same queue as the alert webhooks, with the same retries; see Webhook payloads. The matching email carries the same counts and a button to link.