Skip to documentation content

Monitor entity changes and deliver actionable alerts

Observe accepted entity snapshots, evaluate evidence-backed changes, and route durable alerts through webhook or email.

In this guide
  1. 1Create a change subscription
  2. 2Inspect observed changes
  3. 3Evaluate alert rules
  4. 4Acknowledge and retry deliveries
In this guide
  1. 1Create a change subscription
  2. 2Inspect observed changes
  3. 3Evaluate alert rules
  4. 4Acknowledge and retry deliveries

Changes are semantic records, not raw graph events

A Change Subscription selects canonical entities, fields, relationships, and cadence. Every Observed Change compares two accepted snapshots and retains evidence references. Graph Events remain low-level mutations; use Alerts & Changes when a consumer needs a stable business-level difference.

Subscription → change → rule → alert → delivery

Create a subscription with changes:write. Run it manually or let its cadence trigger a scan. Enabled Alert Rules match severity, change type, entity, and field. A matching change creates one durable Alert and one delivery per configured channel, so delivery retries never duplicate the alert.

Create a monitored entity set

Entity IDs must already be canonical. Keep subscriptions narrow enough that their field and relationship scope reflects a real downstream decision.

cURL
curl -X POST https://api.enrich.nordicdevhouse.com/v1/change-subscriptions \
  -H "Authorization: Bearer enrich_live_••••••••" \
  -H "Content-Type: application/json" \
  -d '{"name":"Nordic account watch","entity_ids":["org_fi_2841842_1"],"fields":["employee_count","credit_status"],"cadence":"daily"}'

Route only material changes

Rules require explicit severities, change types, and channels. Empty entity_ids or fields means all subscribed entities or fields. Webhook deliveries use the same signing controls as enrichment webhooks.

JSON
{
  "name": "Material account changes",
  "severities": ["high", "critical"],
  "change_types": ["field_changed", "relationship_added"],
  "fields": ["credit_status", "employee_count"],
  "channels": ["webhook", "email"]
}

Operate alerts independently from delivery

ResourcePurposeKey scopes
Change SubscriptionSelect entities and monitoring cadencechanges:read / changes:write
Observed ChangeEvidence-backed snapshot differencechanges:read
Alert RuleMatch material changes and channelsalerts:read / alerts:write
AlertDurable actionable state and acknowledgementalerts:read / alerts:write
Alert DeliveryPer-channel attempt and retry statealerts:read / alerts:write

Production checklist

Every write requires a request-specific Idempotency-Key. Delivery workers sign webhook bodies, reject redirects and private targets, and move exhausted retries to the dead-letter state. Configure the entity detector, delivery endpoints, a 32+ character signing secret, an explicit host allowlist, and the worker secret before enabling schedules. Retention defaults to 90 days and is applied by the authenticated worker.

ControlRequirement
Canonical identitySubscribe only to stable Entity Intelligence IDs
EvidencePersist change_id and evidence_refs with downstream decisions
IdempotencyReuse a key only for the exact same request; alert.id remains the durable deduplication key
RetriesRetry delivery resources, never recreate an alert
PermissionsRequire both operation scope and product entitlement
OperationsRun scans, outbox delivery, retention, metrics, and audit through the authenticated worker
Was this page helpful?