Skip to main content
The full v2 events surface is live: fetch events on demand, or enroll entities and receive pushes through webhooks.

​
Two ways to consume events

  • Pull — fetch business events or fetch prospect events on demand, up to 40 IDs per request. The fetch pages also catalog every available event type, from IPO announcements to hiring trends.
  • Push — enroll entities once and receive deliveries as events happen: create an enrollment bound to a webhook via webhook_id.

​
Endpoints

​
Changed from v1

The new_funding_round event payload corrects two field names: See What’s new.

​
Enrollments bind to a webhook

v2 enrollments gain a required webhook_id, referencing a v2 webhook explicitly:
Create enrollment
The binding is strict — the referenced webhook must exist in your scope and be active. Unknown IDs return 404; a missing webhook_id or a webhook with the wrong scope or status returns 422. The system never silently substitutes another webhook. (v1 enrollments have no webhook_id and keep delivering to the legacy partner-level webhook unchanged.) Enrollments also gain a server-generated enrollment_id and a status:
  • active — delivering normally
  • paused — retained but delivering nothing (set when the referenced webhook is force-deleted)
PATCH updates any mutable field — webhook_id, enrollment_key, event_types, or the entity ID list. Re-pointing a paused enrollment to an active webhook reactivates it, without re-enrolling entities. List responses return each enrollment with its enrollment_id, webhook_id, status, event_types, and entity IDs.

​
Delivered payloads carry their source

Event payloads add delivery-source fields so a shared handler can route without relying on enrollment_key alone: webhook_id, tenant_id, partner_id, and enrollment_id, alongside the existing event fields. Signature verification is unchanged — HMAC over timestamp.payload, computed with the secret of the delivering webhook.

Webhooks

Deliver events to your own endpoints — also currently served by v1