Skip to main content
Up2Data pushes two kinds of events to your endpoints: Signal events (a Trigger fired, a Signal paused, a check failed) and batch events (an async enrichment job finished).

Events

Signals created without a notify block use your account’s default webhook. Poll any delivery with GET /v1/webhook-deliveries/{delivery_id}.

Delivery

Every delivery is a POST with two headers:

Verifying signatures

Signatures are HMAC-SHA256 over {timestamp}.{raw_body} using the webhook_secret you set on the Signal (or your account-level secret for batch events).
Compute the HMAC over the raw request body, before any JSON parsing — re-serialized JSON will not match.

Retries & idempotency

  • We expect a 2xx within 10 seconds. Anything else is retried 5 times with exponential backoff (1m → 5m → 30m → 2h → 6h).
  • Retries carry the same trigger_id / job_id — dedupe on it and deliveries are safely idempotent.
  • Ordering is not guaranteed across deliveries. Each Trigger carries a per-Signal monotonic check_number — order by it (or checked_at), never by arrival.
  • If your URL returns 404/410 repeatedly (or exhausts retries on consecutive events), the Signal is auto-paused and a signal.paused event is sent to your account’s fallback endpoint.
Signal webhook payloads include the Signal’s external_id and metadata when set. Trigger history and terminal webhook delivery records are retained for 90 days (all plans today).

Don’t want webhooks?

Everything delivered by webhook is also queryable: GET /v1/triggers for Signal matches, GET /v1/batch/{job_id} for batch results. Polling those endpoints is free.