How AI Agents Find Companies by Event or Intent: An Explorium API Guide

Intent data for AI agents is only as useful as the query language wrapped around it. An agent asked to find every US company actively researching data enrichment that also just expanded its sales team needs intent data for AI agents exposed as filter parameters, not as a weekly CSV drop it has to parse and join on its own.

Most intent vendors still ship dashboards built for humans. The buying signal exists, but the agent cannot compose it with firmographics or events in a single request, which is how uncaptured intent quietly leaks out of pipelines. The Explorium API takes the opposite approach: events and intent are filter keys on company search, sitting next to size, geography, and industry.

This guide walks the full recipe endpoint by endpoint: define the ICP, filter by intent, filter by event, and return a scored cohort the agent acts on in the same session.

Q1: Why Do AI Agents Need Company Cohorts Instead of Lookups?

Agents answer questions shaped like “find the group of companies where X just happened,” so they need a search endpoint that returns a filtered cohort in one call, not a lookup endpoint they hit once per company. A single enrichment lookup tells you about a company you already knew. Cohort search discovers the companies you did not know, filtered to your ICP before a single credit is spent on enrichment.

❌ Why One-at-a-Time Lookups Fail Agent Tasks

• Discovery questions (“who raised a round this month?”) have no input list, so a lookup-only API cannot even start the task.
• Looping lookups over a CRM export burns tokens and credits on companies that were never in the ICP.
• Signal joins happen client-side: the agent stitches intent files, event feeds, and firmographics with brittle matching logic.
• Latency compounds: 500 sequential lookups is 500 round trips before the agent writes a single line of output.

✅ What Cohort Search Enables

• One request expresses the whole question: firmographics, technographics, intent, and events as parallel filters over 150M+ company profiles.
• The response arrives pre-matched with a stable business_id, so downstream enrichment and signal-based outbound loops need no fuzzy joining.
• Pagination is explicit (size up to 60,000, page_size up to 100), so agents plan token budgets before fetching.
• Credits are spent on the filtered cohort only, not on every candidate the agent considered.

Q2: What Signal Families Does the Explorium API Expose: Events and Intent?

The Explorium API exposes two signal families as search filters: business events (an 18-category taxonomy covering roughly 4.3M company events per 90 days) and Bombora-powered buying intent (topic-level composite scores refreshed weekly, with In-Depth, Active, and Early levels). Events tell you what a company just did; intent tells you what it is researching right now. The strongest agent queries use both, a pattern covered in depth in the intent data for AI agents buyer’s guide.

🔄 Events: 18 Categories, Granular event_types Values

• Company events cover IPO announcements, new funding rounds, product launches, partnerships, office openings and closings, department hiring and headcount shifts, M&A, cost cutting, awards, lawsuits, and outages or security breaches.
• The 18 categories expand into granular API values such as hiring_in_sales_department, new_funding_round, and increase_in_engineering_department.
• Three prospect events run alongside them (changed title, changed company, job start anniversary), roughly 500K prospect events per 90 days.
• On search, the events filter takes a last_occurrence window of 30 to 120 days, so recency is part of the query itself.

📊 Intent: Bombora-Powered Topic Scores

• Each company carries topic-level composite scores refreshed weekly; a score above the 60 threshold marks the topic as surging.
• level_of_intent classifies the account: In-Depth Research, Active Research, or Early Research, based on the share of topics above threshold.
• topic_count (“4 / 12”) shows surging topics against total topics evaluated, a ready-made prioritization number.
• On search, business_intent_topics accepts topic strings plus a topic_intent_level value, so intent is a filter, not a post-processing step.

Q3: How Does an Agent Compose the Flow, Endpoint by Endpoint?

The flow is three calls: POST /v1/businesses with ICP filters to define the universe, the same call with intent and event filters added to narrow it, then POST /v1/businesses/events over the matched business_ids to pull event detail. Every call authenticates with a single API_KEY header, and every response carries the same business_id spine that the whole enrichment layer in your agent harness keys on.

🏗️ Step 1: Define the ICP Filter Set

Start with firmographics. This query scopes the universe to US software companies with 201-1000 employees:

curl -X POST https://api.explorium.ai/v1/businesses \
  -H "API_KEY: $EXPLORIUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "preview",
    "size": 1000,
    "page_size": 100,
    "filters": {
      "country_code": { "values": ["us"] },
      "company_size": { "values": ["201-500", "501-1000"] },
      "linkedin_category": { "values": ["software development"] }
    }
  }'

Run preview mode first: it returns the cohort shape and total_results so the agent validates the funnel before spending credits on full records.

📊 Step 2: Add Intent as a Filter

Intent narrows the universe to accounts researching your category right now. Add one key to the same request:

"business_intent_topics": {
  "topics": ["Data Management:Data Enrichment", "Data Management:Data Quality"],
  "topic_intent_level": "high_intent"
}

🔄 Step 3: Confirm Event Detail Over the Cohort

For the matched companies, pull the underlying events with timestamps and source links. The endpoint takes up to 40 business_ids per call, so chunk the cohort:

curl -X POST https://api.explorium.ai/v1/businesses/events \
  -H "API_KEY: $EXPLORIUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "business_ids": ["8adce3ca1cef0c986b22310e369a0793"],
    "event_types": ["hiring_in_sales_department", "new_funding_round"],
    "timestamp_from": "2026-07-20"
  }'

The response returns output_events with event_name, event_time, a stable event_id for dedupe, and a data object that includes a source link the agent cites in its output.

Decision rule for agent builders: filter first, enrich second, fetch event detail last. Every step shrinks the set the next step pays for, which is why the sequence runs at a fraction of the cost of enrich-everything pipelines.

Q4: What Does the Compound Query Look Like in Practice?

The centerpiece query, companies with 200-1000 employees in the US showing high intent on data enrichment topics that also grew their sales team in the last 30 days, is one POST /v1/businesses call with four filters. No dashboard supports this intersection; an agent composes it trivially:

curl -X POST https://api.explorium.ai/v1/businesses \
  -H "API_KEY: $EXPLORIUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "full",
    "size": 1000,
    "page_size": 100,
    "filters": {
      "company_size": { "values": ["201-500", "501-1000"] },
      "country_code": { "values": ["us"] },
      "business_intent_topics": {
        "topics": ["Data Management:Data Enrichment"],
        "topic_intent_level": "high_intent"
      },
      "events": {
        "values": ["hiring_in_sales_department"],
        "last_occurrence": 30
      }
    }
  }'

⚡ One Call, Four Constraints

• company_size maps “200-1000 employees” onto the documented buckets 201-500 and 501-1000.
• business_intent_topics keeps only accounts at high intent on the named topics, backed by weekly Bombora composite scores.
• events with last_occurrence: 30 requires sales-department hiring inside the last 30 days, the minimum window the API supports.
• The response arrives ranked and paginated with business_id, name, domain, and number_of_employees_range on every record.

🔑 Scoring the Response with Intent Detail

To rank the cohort, enrich each match with topic-level scores and sort by surging-topic density:

import requests


BASE = "https://api.explorium.ai/v1"
H = {"API_KEY": KEY, "Content-Type": "application/json"}

cohort = requests.post(f"{BASE}/businesses", headers=H, json=query).json()["data"]
for biz in cohort:
    intent = requests.post(
        f"{BASE}/businesses/bombora_intent/enrich",
        headers=H,
        json={"business_id": biz["business_id"],
              "parameters": {"min_score": 60}},
    ).json()["data"]
    surging, total = intent["topic_count"].split(" / ")
    biz["intent_score"] = int(surging) / int(total)

cohort.sort(key=lambda b: b["intent_score"], reverse=True)

The result is a scored, enriched company list produced inside one agent session: discovery, qualification, and prioritization without a human touching a dashboard.

Q5: Why Should Agents Treat Events and Intent as WHERE Clauses, Not Feeds?

Feeds hand the agent everything that happened and make relevance the agent’s problem; filters hand the agent only the companies that match, which is the difference between an agent that reacts and an agent that targets. A feed consumer spends its context window triaging noise. A filter consumer spends it on the accounts that already passed the ICP, intent, and recency gates server-side.

❌ The Feed Trap

• Raw event feeds arrive unranked, so the agent burns tokens classifying events for companies outside the ICP.
• Client-side joins between an intent file and an event feed fail on naming mismatches that a matched business_id spine avoids entirely (Explorium matches at 97.8%+ accuracy).
• Feeds invert control: the data decides what the agent looks at, instead of the task deciding what data to pull.

💡 Filters Compose, Feeds Accumulate

• WHERE clauses stack: each added filter multiplies precision without new infrastructure or storage.
• The same taxonomy powers both modes, so a query tested interactively becomes a monitoring job without rewrites.
• Pull-based cohorts fit request-response agents; when a workflow genuinely needs push delivery, event-driven agents on Explorium webhooks cover that pattern with the same event types.

Q6: How Do You Get Started with the Explorium API?

Sign up for a free Explorium account at explorium.ai, create an API key, and the first cohort call runs in minutes: no sales call, no per-endpoint credit allocation, one unified pool across search, events, and enrichment. The same key also serves the GTM brain architecture when the agent graduates from cohort pulls to a full data layer.

🚀 From First Call to Production

• Step 1: Create the free account and generate an API key from the dashboard.
• Step 2: Run the Q3 ICP query in preview mode and sanity-check total_results.
• Step 3: Add business_intent_topics and events filters one at a time, watching how each narrows the cohort.
• Step 4: Wire the compound query into your agent as a tool, with page_size and last_occurrence as arguments the model sets.
• Step 5: Scale out: bulk endpoints take up to 1,000 entities per call at 100 QPS when the agent moves from discovery to enrichment.

🔑 The Decision Framework

Pick the Explorium API when your agent needs discovery plus qualification in one request: 150M+ companies searchable by 18 event categories and Bombora-powered intent levels, matched at 97.8%+ accuracy, billed from a unified credit pool. If the workflow is a lookup on companies you already know, any enrichment API works. The moment the question starts with “find every company where,” compound filters are the only architecture that answers it in one call.

Related Posts

• Event-Driven AI Agents with Explorium Webhooks: The Push Pattern
• Intent Data for AI Agents: The 2026 Buyer’s Guide
• Building a Signal-Based Outbound Loop for AI Agents

Frequently Asked Questions

What event types does the Explorium business events API support?

The taxonomy covers 18 event categories that expand into granular event_types values on the API. Categories include IPO announcements, new funding rounds, new investments, product launches, partnerships, office openings and closings, department-level hiring, headcount increases and decreases by department, executive and employee joins, awards, cost cutting, mergers and acquisitions, lawsuits and legal issues, and outages or security breaches.

• Granular values look like hiring_in_sales_department, new_funding_round, increase_in_engineering_department, and merger_and_acquisitions.
• Coverage runs at roughly 4.3M company events per 90 days, refreshed daily and weekly depending on event type.
• On search, the events filter accepts a last_occurrence window between 30 and 120 days; on POST /v1/businesses/events, timestamp_from and timestamp_to give precise date control.

How does Bombora-powered intent data work in the Explorium API?

Explorium sources business intent from Bombora and exposes it two ways. As a search filter, business_intent_topics accepts topic strings plus a topic_intent_level value, so intent becomes a WHERE clause on POST /v1/businesses. As an enrichment, POST /v1/businesses/bombora_intent/enrich returns topic-level detail for one business_id.

• Each topic carries a weekly composite score; the documented min_score floor is 60, and scores above it mark a surging topic.
• level_of_intent classifies the account as In-Depth Research, Active Research, or Early Research based on the share of topics above threshold.
• topic_count returns a ratio like 4 / 12 (surging topics over topics evaluated), which agents use directly as a prioritization score.
• date_stamp in every response shows the weekly refresh date, so agents verify freshness programmatically.

Can an AI agent filter companies by intent and event in the same API call?

Yes. POST /v1/businesses accepts business_intent_topics and events inside the same filters object, alongside firmographic keys like company_size and country_code. That is the compound query pattern: companies with 200-1000 employees, US, high intent on data enrichment topics, that also grew their sales team in the last 30 days, in one request. The server evaluates all filters before returning results, so the agent never downloads a candidate that fails any condition. This is the core difference between the Explorium API and intent tools that only export topic reports: the intersection of intent, event recency, and ICP happens in the database, not in the agent’s context window. Filters stack freely, so adding technographics (company_tech_stack_tech) or revenue bands (company_revenue) narrows the same query without new endpoints.

How many companies can an agent pull per API call?

POST /v1/businesses supports a size of up to 60,000 matched companies per query, delivered in pages of up to 100 records via page_size and page parameters. Event detail on POST /v1/businesses/events takes up to 40 business_ids per call, so agents chunk larger cohorts. For enrichment at scale, bulk endpoints process up to 1,000 entities per call, and the platform sustains 100 QPS, which puts a 10,000-company enrichment run in the minutes range rather than hours. The practical pattern for agents: search in preview mode to size the cohort, page through full results only for the slice you intend to act on, then batch enrichment calls. Credits draw from one unified pool across all endpoints, so there is no per-endpoint allocation to forecast.

What is the difference between company events and prospect events?

Company events attach to a business_id and describe organizational changes: funding, hiring, offices, M&A, product launches, and the rest of the 18-category taxonomy, at roughly 4.3M events per 90 days. Prospect events attach to individual people and cover three types: changed title, changed company, and job start anniversary, at roughly 500K events per 90 days. Both flow through the same events API surface (entity_type distinguishes business from prospect), and both work as triggers for outreach agents. The common pattern pairs them: a company event (new sales hiring) finds the account, then prospect events (a new VP just changed company into that account) find the person and the timing for the message.

How fresh is the event and intent data an agent gets back?

Events refresh daily and weekly depending on event type, and every event record carries an event_time timestamp plus a stable event_id for dedupe, so agents enforce their own recency rules. On search, last_occurrence bounds results to a 30-120 day window; on the events endpoint, timestamp_from and timestamp_to accept ISO dates for exact control. Intent scores refresh weekly: the bombora_intent enrichment returns a date_stamp field in YYYYMMDD format showing the score date, and composite scores are recomputed against the 60-point threshold each cycle. An agent that logs event_id values and compares date_stamp across runs detects both new signals and decayed ones, which is exactly the loop that keeps a cohort current without refetching everything.

How much does the Explorium API cost to run under an agent?

Explorium uses a credit model with one unified pool across every endpoint: search, events, intent enrichment, and contact enrichment all draw from the same balance, with no per-endpoint allocation and no seat tax. A free account requires no sales call and gets you an API key with trial credits, so the first cohort query runs in minutes. Cost control is structural in the flow this guide teaches: preview mode sizes a cohort before full records are fetched, filters shrink the set server-side before enrichment is paid for, and the 40-id chunking on event detail keeps calls proportional to the cohort you actually act on. Agents that filter first and enrich second spend credits only on companies that already passed every gate.

Does the Explorium API work with agent frameworks, and is REST the right integration path?

REST is the most portable path: every agent framework that can call a tool can wrap POST /v1/businesses, and the three-endpoint flow in this guide maps one-to-one onto tool definitions with page_size, topics, and last_occurrence as model-settable arguments. Explorium also ships an MCP server for agent frameworks; this guide covers the REST path. For REST integrations, give the agent three tools (search_companies, fetch_events, enrich_intent), pass the API_KEY header from environment configuration rather than the prompt, and return total_results to the model so it reasons about cohort size before paginating. That structure keeps the agent deterministic about cost and lets the same tools serve chat agents, scheduled jobs, and batch pipelines.