Skip to main content

Just want working code?

Stop reading and copy the Monitors coding agent reference into your agent. It is self-contained, including webhook signature verification.

Monitors are the standing half of Arcmira: a Search interest that keeps firing as new media lands. The model is two nouns:
  • A tracker watches one entity (by name + type) and fires whenever new media matching it is analyzed.
  • A monitor is a named group of trackers with shared delivery settings: email cadence, a Slack channel, a webhook endpoint.
Tracking is entity-level, not keyword-level. A tracker on Apple (organization) will not fire for fruit, and a tracker on the topic weather modification catches the concept however it is phrased.

​
Key capabilities

CapabilityWhat it does
TrackersWatch any person, organization, product, topic, or channel
MonitorsGroup trackers; own the delivery settings
Email deliveryrealtime, hourly, or daily digests with configurable day/time
Slack deliveryOne-click OAuth in the dashboard, then route alerts to a channel
Webhook deliveryHMAC-signed POSTs to your endpoint, with retries and auto-disable
Alert historyPoll the last N deliveries per monitor or tracker
Every alert is evidence, not just a ping: the matched entity and tracker, the video and channel, the exact timestamp, sentiment, a context quote, and a deep link to watch the moment.

​
Common use cases

Track your organization and your competitors; alerts land in Slack minutes after a new episode is analyzed, with the clip and the sentiment. Amplify the praise while it’s hot, answer the attack before it trends.
Track a topic entity. Know the moment fringe or mainstream voices pick it up, with sentiment per mention.
Create monitors and trackers programmatically from your CRM or portfolio list, deliver to a webhook, and drive your own dashboards or the next agentic action.

​
Quickstart: the full lifecycle

1

Create a monitor with delivery settings

curl -X POST 'https://api.arcmira.com/v1/monitors' \
  -H "Authorization: Bearer $ARCMIRA_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Competitor watch",
    "icon": "radar",
    "color": "indigo",
    "notifyEmails": ["ops@example.com"],
    "notifyFrequency": "realtime",
    "notifyWebhook": true,
    "webhookUrl": "https://example.com/hooks/arcmira"
  }'
Requires monitors:write. Webhook delivery is a paid-tier feature; Slack is available from Free.
2

Create a tracker, then attach it

Trackers are created standalone, then attached to a monitor by ID:
curl -X POST 'https://api.arcmira.com/v1/trackers' \
  -H "Authorization: Bearer $ARCMIRA_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "entityName": "Ramp", "entityType": "organization" }'
# -> { "tracker": { "id": "trk_9f2ab4c8d1e6", ... } }

curl -X POST 'https://api.arcmira.com/v1/monitors/mon_abc123/trackers' \
  -H "Authorization: Bearer $ARCMIRA_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "trackerIds": ["trk_9f2ab4c8d1e6"] }'
entityType is one of person, organization, product, topic, channel. Trackers left standalone still fire; they use their own per-tracker delivery settings instead of the monitor’s.
3

Verify with alert history

curl 'https://api.arcmira.com/v1/monitors/mon_abc123/alerts?n=25' \
  -H "Authorization: Bearer $ARCMIRA_API_KEY"
Every delivery attempt is a row: channel, status, timestamps, and the tracker that fired. Use it to verify your integration end-to-end or to power a recent-activity feed.
4

Receive and verify webhooks

Deliveries are HMAC-signed (X-Arcmira-Signature). Verification code and the full payload schema live in the coding agent reference.

​
Choosing well

  • Tracker vs monitor. One entity to watch: a tracker. A program of entities sharing a destination (a Slack channel per client, a webhook per environment): a monitor. Per-tracker delivery overrides exist for exceptions; don’t build one monitor per entity.
  • One-shot vs standing. If you only need the answer today, pull Search mentions and skip tracking. Trackers earn their keep when the interest outlives the query.
  • Realtime vs digest. realtime email/Slack/webhook for anything you’d act on within the hour (brand defense, crisis). daily digests for awareness-level interests; they batch to digestTime.
  • Alert cost. Each fired occurrence debits 100 rows from the shared pool, once per occurrence regardless of how many channels it fans out to.
  • Polling vs webhooks. Webhooks push within minutes of analysis. Poll alert history when you can’t host an endpoint, when auditing delivery, or when backfilling after downtime; the two compose (webhook for speed, polling for reconciliation).

​
Constraints

  • Scopes: monitors:write / trackers:write for mutations; read for all GETs. Send Idempotency-Key on every POST/PATCH.
  • Alerts bill 100 rows per fired occurrence; monitor and tracker CRUD is free.
  • Delivery tiers: Slack from Free; realtime email and webhooks on paid tiers (Free email is daily digest).
  • Alerts fire for recently published media (roughly a 14-day publish window) as it is analyzed; this is monitoring, not retroactive search. Backfill history with Search.
  • Matching is by resolved entity (name + type), the same resolution Search uses.
  • If a usage cap pauses delivery, missed alerts are surfaced in the dashboard and can be replayed once the cap lifts.

​
Community Review

Any alert that fired is disputable, free, with type: "monitor_alert" on POST /v1/feedback: wrong entity, wrong media, duplicate, should-not-have-fired, or the inverse, a missed_alert you expected (submitted with the video URL as evidence). Corrections key off the alert row ID from alert history, and you can check review status later with GET /v1/feedback/{feedback_id}. Details and the full issue set: Community Review.

​
Next