Competitor Monitoring
Get Competitor Alerts
Where competitor alerts go, and when an account alerts
GET
Read the competitor alert setting: whether alerts go out, the Slack channel and the email for
each use case, the webhook, the Attack threshold and its scope, and how far back a single
interaction still alerts. Change it with
Update Competitor Alerts.
Each alert is sent on its own. A Defense alert (an interaction on one of your customers)
posts in
defense_slack_channel_id and names the account’s CS owner; an Attack alert (a
critical comment, or an account over the threshold, on a non-customer) posts in
attack_slack_channel_id and names the account’s owner. Both owners come from the fields you
map in your CRM, read live when the alert is sent; with no owner, the alert names nobody.
When email is on for a use case, each alert is also emailed to its owner and to that use
case’s extra addresses. When the webhook is on, every alert is also POSTed to webhook_url;
see Webhook payloads.
On, with nowhere to send yet. A workspace that never saved the setting reads as
enabled: true, for customers and target accounts, with the threshold at 10 interactions in
30 days per competitor, a 14-day history window, no channel, no email and no webhook, and
is_default: true. has_delivery is false until a channel, an email or the webhook is
set: until then, no alert is sent.Authorizations
The API key you created on the API settings page of the Clustr app.
Query Parameters
Optional. An account's Clustr ID (acc_…); its LinkedIn numeric id also works. Also returns
account: the owner an Attack alert on it names (its owner in your CRM, from the last CRM
sync), with owner_source crm_owner, or owner: null and owner_source: "none" when your
CRM names nobody. recipients lists who an Attack alert on it is emailed to when Attack email
is on.