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 signal_score descending), 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 the signal score works

signal_score weights each interaction by its type (comments score higher than reactions), applies recency decay (interactions in the last 6 months count fully; older ones decay toward 0.7x past 24 months), and adds a bonus for the target’s seniority. The per-account total is then multiplied by the number of distinct competitor reps that touched the account, so concentrated, multi-rep pushes rank highest.

Example report

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

Report-ready webhook

If your workspace has webhook delivery enabled, Clustr POSTs a competitor_monitoring.report_ready event to your configured URL when a run completes. The payload is a summary plus a deep link; fetch the full report by id for the detail.
The matching email notification carries the same attack/defend counts, the interactions and people-tracked totals, and a “View Full Report” button to report_link.