---
title: "Event-Driven AI Agents: Explorium Webhooks Setup Guide"
description: "Register a B2B events webhook, enroll accounts 20 at a time, and let Explorium push funding and hiring events straight to your AI agent, no polling."
canonical: "https://www.explorium.ai/blog/building-ai-agents/event-driven-ai-agents-explorium-webhooks-2026/"
last-updated: "2026-08-20"
---

# Event-Driven AI Agents: Explorium Webhooks Setup Guide

> Register a B2B events webhook, enroll accounts 20 at a time, and let Explorium push funding and hiring events straight to your AI agent, no polling.

- Canonical URL: https://www.explorium.ai/blog/building-ai-agents/event-driven-ai-agents-explorium-webhooks-2026/
- Last updated: 2026-08-20

A B2B events webhook turns company news into an HTTP POST that lands on your agent's endpoint the moment Explorium detects it. Instead of an agent polling for changes on a schedule, the B2B events webhook makes the event itself the trigger that wakes the agent: a funding round is announced at 9:04, your handler has the payload at 9:04, and a drafted email is waiting for approval at 9:05.

That gap is the whole game, because a buying signal is worth its age. In the first piece of this series you built pull-based cohorts with [agents that find companies by event or intent](https://www.explorium.ai/blog/building-ai-agents/ai-agents-find-companies-by-event-or-intent-2026/). Pull works for weekly list builds. It does not work for moments.

This guide covers the push half: register a webhook, prove it receives traffic, enroll your target accounts, and wire the handler that routes each notification to the right agent. Every endpoint and payload shape below is verified against the current Explorium webhooks reference.

## Q1: Why Does Polling for Company Events Fail AI Agents?

**Polling fails because the agent pays for every empty check and still misses the window between checks: a 6-hour cron loop runs 4 times a day and can still deliver a funding event 5 hours and 59 minutes late.**

### ❌ The Cron-Polling Tax

- **Token burn on empty reads:** most polls return nothing new, yet the agent still loads, diffs, and reasons over the same account list every cycle.

- **A latency floor equal to your interval:** whatever cadence you pick becomes the worst-case delay between a signal firing and your team knowing.

- **State bookkeeping:** polling forces you to build and maintain a "what changed since last run" diff layer that the data provider already has.

- **Quota pressure:** scanning a 2,000-account list on every cycle spends API calls on accounts where nothing happened.

### ✅ What Push Changes

- **Zero standing compute:** the agent sleeps until an HTTP POST arrives, so cost scales with events, not with the size of your account list.

- **Latency equals detection to delivery:** the interval disappears from the equation entirely.

- **Pre-attributed payloads:** each notification names the business_id, event_name, and event_time, so no diffing is required.

- **Captured moments:** push saves the signals that never survive a dashboard review cycle, the gap covered in [uncaptured intent](https://www.explorium.ai/blog/data-for-gtm/uncaptured-intent-2026/).

## Q2: What Is a B2B Events Webhook in Explorium?

**A B2B events webhook is a registered HTTPS endpoint that Explorium calls with a signed JSON notification whenever an enrolled company triggers a monitored event, drawn from 18 buying-signal categories across 150M+ company profiles and 800M+ professional profiles.** You control three things: where notifications land (the webhook), which companies and events fire them (enrollments), and how they route once received (the enrollment_key).

### 🏗️ The Architecture in One Pass

- **Webhook:** one endpoint URL per partner_id; registering again rotates the secret and replaces the previous configuration.

- **Enrollments:** lists of business IDs paired with the event types you want watched, tagged with a key you choose.

- **Notifications:** signed POSTs carrying event_id, event_name, business_id, enrollment_key, and event-specific data.

- **Your handler:** verifies, dedupes, and routes; everything downstream is your agent logic.

### 📊 The Event Taxonomy Agents Act On

The taxonomy spans 18 buying-signal categories, and department-level variants expand the enrollment vocabulary to 35 event identifiers. The ones outbound agents use most:

Event categoryIdentifierAgent play

New funding roundnew_funding_roundBudget just landed; open the expansion conversation
New executive level hiresemployee_joined_companyCongrats-with-context outreach to the new leader
New office openingnew_officeTerritory and local-presence play
Merger and acquisitionsmerger_and_acquisitionsRe-qualify the account; stack consolidation review
Outages and security breachesoutages_and_security_breachesTimely help, not a pitch
IPO announcementipo_announcementCompliance and scale tooling conversation

> A signal is worth its age. The funding event that opens a conversation in hour one reads as spam by week three. Push architecture exists to keep you in hour one.

## Q3: How Do You Register and Validate the Webhook Endpoint?

**Registration is a single POST to /v1/webhooks with your partner_id and endpoint URL, and validation is a POST to /webhooks/check_connectivity, which fires simulated events at your endpoint so you test the full delivery path before any real signal flows.** The endpoint itself is your agent's ingress: a serverless function, an n8n or Trigger.dev webhook node, or the HTTP handler inside your agent runtime.

### ✅ Step 1: Register the Endpoint

```
`curl -X POST https://api.explorium.ai/v1/webhooks \
  -H "api_key: $EXPLORIUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "partner_id": "acme_gtm",
    "webhook_url": "https://agents.acme.com/hooks/explorium"
  }'`
```

The response returns a webhook_secret. Store it in your secret manager: it signs every notification you will receive. Two behaviors to plan around: each partner_id holds exactly one webhook URL, and re-registering generates a new secret while replacing the old configuration. Optional fields attach custom headers and set payload_format to json or stringified_json.

### 🔄 Step 2: Prove It Receives Events

```
`curl -X POST https://api.explorium.ai/v1/webhooks/check_connectivity \
  -H "api_key: $EXPLORIUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "partner_id": "acme_gtm",
    "simulation": { "event_name": "funding_round", "number_of_events": 3 }
  }'`
```

The simulation block sends synthetic events of a named type (funding_round, new_office, closing_office, new_investment, outages_and_security_breaches) so your handler processes realistic payloads. Confirm in your logs that the POSTs arrived, the handler returned 200, and the parsed fields match your routing logic before you enroll a single account.

## Q4: How Do You Enroll Accounts and Route Events with enrollment_key?

**Enrollment is a POST to /v1/businesses/events/enrollments with up to 20 business IDs and the event types to watch, and the enrollment_key you choose is echoed back in every notification, so one key per campaign, territory, or agent routes each event to the right worker.** There is no cap on total enrollments, only 20 IDs per request, so a 2,000-account list is 100 sequential calls.

### 🚀 Step 3: Enroll the Accounts You Care About

```
`curl -X POST https://api.explorium.ai/v1/businesses/events/enrollments \
  -H "api_key: $EXPLORIUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "enrollment_key": "east_enterprise_q3",
    "event_types": ["new_funding_round", "employee_joined_company", "new_office"],
    "business_ids": [
      "57e7fd862b2ac1c9358bccf8e90faeb1",
      "a3f1c09e77b24d1c8e5f6a2b91d04c77"
    ]
  }'`
```

Business IDs are 32-character hex strings, so resolve your CRM domains through Explorium's matching layer first; company matching runs at 97.8%+ accuracy. The response confirms the enrollment_key and returns an enrollment_id such as en_7b429a01.

### 🔑 One Key per Campaign, Territory, or Agent

- **east_enterprise_q3** routes to the enterprise outbound agent for that territory.

- **churn_risk_accounts** routes to a customer-success agent instead of sales.

- **competitor_watch** routes to a daily digest, because not every event deserves an action.

- **Keys are minimum 4 characters:** make them readable, since the key appears in every payload, log line, and trace.

## Q5: What Should the Agent Do When an Event Arrives?

**On receipt, the handler verifies the X-Signature header, dedupes on event_id, routes on enrollment_key, and only then hands the agent a payload that already names the company, the event, and the timestamp.** Keep the handler thin and synchronous, and push the reasoning work to a queue.

### 📥 The Notification Payload

```
`{
  "event_id": "691377c2df80547c70e26a13216a3944",
  "event_name": "employee_joined_company",
  "business_id": "57e7fd862b2ac1c9358bccf8e90faeb1",
  "enrollment_key": "east_enterprise_q3",
  "enrollment_id": "en_7b429a01",
  "event_time": "2026-08-19 09:04:12.703000+00:00",
  "partner_id": "acme_gtm",
  "tenant_id": "con_dJJUz1jfqdwzfM4t",
  "data": { }
}`
```

The data object carries event-specific fields, and each delivery arrives with X-Signature (an HMAC-SHA256, base64url encoded) and X-Timestamp headers for verification and replay protection.

### ⚡ The Handler Sketch

```
`@app.post("/hooks/explorium")
def handle_event(request):
    verify_hmac(request.headers["X-Signature"],
                request.headers["X-Timestamp"], request.body)
    event = json.loads(request.body)
    if already_processed(event["event_id"]):
        return 200
    mark_processed(event["event_id"])
    route(event["enrollment_key"]).enqueue(event)
    return 200`
```

Downstream, the agent runs the same loop every time an event dequeues:

- **Enrich in-flight:** pull current firmographics and technographics for the business_id so the draft reflects today, not last quarter.

- **Check ICP fit:** not every enrolled account stays qualified; score before acting.

- **Score the moment:** a Series C at a target account outranks an award at a marginal one.

- **Draft the action:** an outreach draft, a CRM field update, or an owner alert, the same pattern as the [signal-based outbound loop](https://www.explorium.ai/blog/building-ai-agents/signal-based-outbound-loop-2026/).

## Q6: How Does the Worked Example Run: New Exec Hire to Drafted Email?

**Enroll your target accounts for employee_joined_company, and when the event fires the agent pulls the new executive's profile, drafts a congrats-with-context email, and queues it for human approval, the same flow Explorium documents in its event-triggered outreach reference.**

### 🔄 The Six-Step Flow

- **Enroll:** the target-account list goes in under enrollment_key exec_hire_plays with event type employee_joined_company.

- **Event fires:** the handler receives a signed notification naming the business_id and event_time.

- **Enrich:** the agent fetches prospects filtered by business_id, department, and seniority (cxo, vp, director), keeping the top 5 relevant people.

- **Compose:** the draft references the new role, the department, and one account-specific fact from the enrichment pass.

- **Review:** the draft posts to an approval queue; a human clicks send.

- **Log:** event_id, actions taken, and outcome land in the trace store.

### ✅ Why Human Approval Stays in the Loop

Event-triggered sends are high-yield and high-blast-radius: the same automation that congratulates a new CRO in minutes also emails 40 people in one morning if an enrollment is misconfigured. Keep a human on the send button and enforce per-key rate caps, the guardrail pattern from [GTM runtime controls](https://www.explorium.ai/blog/building-ai-agents/gtm-runtime-controls-2026/).

## Q7: How Do You Keep Webhook Agents Reliable in Production?

**Three habits keep an event-driven agent trustworthy: dedupe on event_id because delivery is at-least-once, verify the HMAC signature on every POST, and reconcile enrollments against your account list on a schedule.** Silent failures in a push system look identical to quiet weeks. Wire the handler into the same trace store as the rest of your stack, per [GTM agent tracing](https://www.explorium.ai/blog/building-ai-agents/gtm-agent-tracing-2026/).

### ⚠️ Idempotency: Treat Delivery as At-Least-Once

- **Persist processed event_ids** in a store with a TTL, and check before acting; duplicate deliveries happen.

- **Make side effects repeat-safe:** a re-run should update the same CRM record, not create a second draft.

- **Return 200 fast, process async:** a slow handler invites re-delivery of work you already accepted.

- **Never dedupe on business_id alone:** one company legitimately fires many distinct events.

### 🛡️ Signature Checks and Enrollment Hygiene

RiskSymptomFix

Duplicate deliveryTwo identical drafts for one eventDedupe on event_id before any side effect
Spoofed POSTEvents for accounts you never enrolledVerify X-Signature HMAC and reject stale X-Timestamp values
Stale enrollmentsOutreach drafted for churned or closed accountsWeekly reconcile: get enrollments, diff against CRM, update or delete
Secret driftSignature failures after a re-registrationOne webhook per partner_id; treat registration as secret rotation

## Q8: Getting Started: Free Account to First Event in 5 Steps?

**Explorium is the event layer to build on because it combines coverage (150M+ companies, 18 buying-signal categories), scale (100 QPS, 20 IDs per enrollment call with no total cap), and cost control (a unified credit pool, a free account, and a first API call in minutes).**

### 🚀 The 5-Step Path

- **Step 1:** Create a free Explorium account and generate an API key; no sales call required.

- **Step 2:** Register your endpoint at POST /v1/webhooks and store the webhook_secret.

- **Step 3:** Run /webhooks/check_connectivity with a simulation and confirm 200s in your logs.

- **Step 4:** Match your account list to business IDs and enroll it in batches of 20.

- **Step 5:** Ship the handler (verify, dedupe, route) and watch the first live event wake your agent.

### 🔑 The Decision Framework

Use pull (the events and cohorts pattern from piece one) when you build lists on a schedule. Use push (this guide) when the value of a signal decays by the hour. Most production GTM agents run both against the same Explorium account and the same credit pool. For how event signals compare with third-party intent feeds, read the [intent data for AI agents buyer's guide](https://www.explorium.ai/blog/data-for-gtm/intent-data-for-ai-agents-2026/), piece three of this series.

> The full payload schemas, event catalog, and enrollment endpoints live in the [Explorium webhooks reference](https://developers.explorium.ai/reference/webhooks). Register the endpoint today and your agent stops checking for news and starts receiving it.

## Related Posts

- [How AI Agents Find Companies by Event or Intent](https://www.explorium.ai/blog/building-ai-agents/ai-agents-find-companies-by-event-or-intent-2026/)

- [Intent Data for AI Agents: The Buyer's Guide](https://www.explorium.ai/blog/data-for-gtm/intent-data-for-ai-agents-2026/)

- [The Signal-Based Outbound Loop](https://www.explorium.ai/blog/building-ai-agents/signal-based-outbound-loop-2026/)

## Frequently Asked Questions

### How do I set up an Explorium webhook for an AI agent?

Three API calls stand between a free account and a live event feed. First, register your endpoint with POST /v1/webhooks, passing your partner_id and the HTTPS URL of your agent's ingress (a serverless function, an n8n or Trigger.dev webhook node, or your agent runtime's HTTP handler); the response returns a webhook_secret that signs every future notification. Second, validate the path with POST /v1/webhooks/check_connectivity, optionally adding a simulation block that fires synthetic events (for example funding_round with number_of_events set to 3) so your handler processes realistic payloads before anything real flows. Third, enroll the companies you want monitored with POST /v1/businesses/events/enrollments, passing an enrollment_key, the event_types to watch, and up to 20 business IDs per request. From that point Explorium pushes a signed JSON notification to your endpoint every time an enrolled company triggers a monitored event, and your handler routes it by enrollment_key.

### What event types can Explorium push to a webhook?

Explorium's taxonomy covers 18 buying-signal categories, and department-level variants expand the enrollment vocabulary to 35 event identifiers. The business-event categories include new funding rounds (new_funding_round), new investments, IPO announcements (ipo_announcement), new product launches, new office openings (new_office), office closings, new partnerships, company awards, hiring by department, department workforce trends, new executive level hires (employee_joined_company), lawsuits and legal proceedings, outages and security breaches, cost cutting, and mergers and acquisitions. Prospect-side events, such as a tracked contact changing companies, are enrolled separately through the prospects enrollments endpoint. For outbound agents, the highest-yield triggers are funding rounds (budget arrived), executive hires (new decision maker), office openings (territory expansion), and department hiring surges (growth that implies tooling spend).

### What is the enrollment_key and how should I structure it?

The enrollment_key is a string you choose (minimum 4 characters) when you enroll companies for event monitoring, and Explorium echoes it back inside every webhook notification. That makes it your routing layer: because each partner_id holds exactly one webhook URL, all events land on one endpoint, and the key is how your handler decides which worker gets the event. The pattern that scales is one key per campaign, territory, or agent: east_enterprise_q3 routes to the enterprise outbound agent, churn_risk_accounts routes to a customer-success agent, competitor_watch routes to a daily digest instead of an action. Keep keys human-readable, since they appear in every payload, log line, and trace, and register the mapping from key to worker in one place so a new enrollment cannot silently arrive unrouted.

### How many accounts can I enroll for event monitoring?

Each POST to /v1/businesses/events/enrollments accepts between 1 and 20 business IDs, and there is no cap on the total number of enrollments across requests. A 2,000-account territory is 100 sequential enrollment calls, comfortably inside Explorium's 100 QPS ceiling, so even a large book enrolls in seconds. Business IDs are 32-character hex strings, so resolve your CRM domains through Explorium's matching layer first; company matching runs at 97.8%+ accuracy across 150M+ company profiles. Credits draw from a unified pool rather than per-endpoint allocations, so enrollment volume does not require forecasting a separate quota. The practical limit is operational, not technical: enroll the accounts your agents are actually staffed to act on, because an event feed wider than your approval capacity just builds a queue.

### How do I verify that webhook notifications really come from Explorium?

Every delivery arrives with two verification headers. X-Signature carries an HMAC-SHA256 signature, base64url encoded, computed with the webhook_secret returned when you registered the endpoint; recompute it on your side and compare with a constant-time check before trusting the payload. X-Timestamp carries a Unix timestamp for replay protection; reject requests whose timestamp falls outside a short window so a captured request cannot be replayed later. You can also inject your own authorization header at registration time via the optional headers parameter, which gives you a second, independent check at your gateway. Two operational notes: re-registering the webhook generates a new secret and replaces the old configuration, so treat registration as a secret-rotation event, and store the secret in a secret manager rather than in the handler's source.

### How should an agent handle duplicate webhook events?

Treat delivery as at-least-once and make the handler idempotent on event_id, the unique identifier included in every notification. The working pattern: persist processed event_ids in a fast store with a TTL, check the store before triggering any side effect, and return 200 immediately while the real work runs from a queue, because a slow response is the most common cause of re-delivery. Design the side effects themselves to be repeat-safe: a second run of the same event should update the same CRM record and refresh the same draft, never create a second email. Do not dedupe on business_id or on the event_name alone, since one company legitimately fires many distinct events in a week, and two funding events months apart are both real. Duplicate handling is the difference between an agent your reps trust and one that double-messages a prospect.

### Does Explorium support prospect-level events like job changes?

Yes. Business events and prospect events run on parallel tracks: company-level signals (funding, offices, hiring, M&A) enroll through POST /v1/businesses/events/enrollments, while prospect-level signals, including a tracked contact changing companies, enroll through the prospects enrollments endpoint. Both feed the same registered webhook and both carry an enrollment_key for routing, so one handler serves both streams. The prospect track is what powers the classic champion-tracking play: enroll the buyers and users from closed-won deals, and when one moves to a new company the agent gets the event, enriches the new employer against Explorium's 800M+ professional profiles and 150M+ company profiles, checks ICP fit, and drafts a re-engagement note while the move is still news. Piece one of this series covers pulling these events in batch; the webhook track delivers them the moment they are detected.

### How do I keep enrollments in sync with my account list?

Reconcile on a schedule rather than trusting write-time hygiene. Explorium exposes the full lifecycle: get enrollments to read what is currently monitored, update enrollments to change event types or membership, and delete enrollments to remove them. The weekly loop that works: pull current enrollments per key, diff against the source-of-truth segment in your CRM, enroll the additions in batches of 20, and delete the accounts that churned, closed, or left the segment. Skipping this is the most common event-driven failure mode, and it fails embarrassingly: the agent drafts a congratulations email for an account that churned two months ago, or misses a funding round at an account added last week. Alerting on the diff size also catches silent breakage, because a reconcile that suddenly wants to add 500 accounts usually means the upstream segment changed definition.