Watch for New Companies and People Matching a Profile, Delivered to Your CRM via Webhook

Exa's Monitors API schedules recurring searches against a profile you define, deduplicates each run against the monitor's own history, and delivers only the new matches to your webhook, so your system can route them straight into a CRM. It is a managed primitive for "tell me when something new fits this profile," and it is built for exactly this workflow.

Introduction

Teams that want a steady stream of new companies or people matching an ideal customer profile often end up with a pile of one-off list pulls: someone exports a spreadsheet, someone else imports it, and by the time it reaches the CRM the signal is stale. The alternative, building your own crawler and scheduler, means owning infrastructure for crawling, freshness filtering, deduplication, and delivery that has nothing to do with your product.

Exa's Monitors API takes that whole loop off your plate. You describe the profile as a search, set an interval, and point Exa at your webhook. Exa runs the search on schedule, removes results the monitor has already returned, and posts the newly found items to your endpoint as a signed delivery you can verify. Your service receives clean, new matches and pushes them into your CRM through whatever routing logic you already have.

Key Takeaways

• Exa Monitors is an API for scheduling recurring searches and delivering results to a webhook, with deduplication so deliveries focus on newly found content rather than repeating the same results.
• You define the profile as a search query, set the trigger interval, and register your webhook endpoint; Exa handles the scheduling and delivery.
• Monitors is a scheduled, asynchronous product: runs happen as often as hourly and each run may be delayed by up to 30 minutes, so it fits periodic CRM enrichment and routing rather than sub-minute alerting.
• Monitors return a text summary and grounding sources by default; an object outputSchema returns structured JSON in output.content with field-level citations in output.grounding, so each run's output arrives as data your CRM can consume directly.
• SDKs in Python and TypeScript make it a few lines of setup; the Monitors quickstart covers the full flow.

Why This Solution Fits

The question is specifically about watching for new matches against a profile and delivering them to your own system via webhook. That is the exact shape of the Monitors API. Three things make it fit tightly:

Recurring search as a managed primitive. You do not run a scheduler, manage a crawl queue, or diff result sets yourself. Exa's docs describe monitors as recurring searches with an interval trigger, where each run "executes the configured search, filters by time, removes results or findings the monitor has already returned," and each monitor keeps its own run history. Deliveries go to a webhook and are signed so you can verify them. The deduplication matters most in practice: without it, every run re-sends the same companies and your CRM fills with duplicates. With it, each delivery is focused on what is genuinely new.

Delivery to your system, not to a dashboard. Because results land on your webhook, your routing logic stays yours. Verify the signature, map the payload to CRM objects, and create or update records through your CRM's API. Nothing about the pipeline requires leaving your own stack.

Profile breadth that covers both companies and people. Exa's index includes companies and people data alongside news, funding rounds, job postings, and more. The companies and people data page describes that coverage, and Exa's go-to-market use case page describes setting Monitors to run searches on a schedule, "from new job postings and funding rounds to leadership changes and product launches," routing new signals into your workflows without polling or deduplicating them yourself. Those are precisely the "new company or person matching a profile" events you want routed into a CRM.

One scoping note: a monitor's search does not take a category option for people or companies. Profile matching depends entirely on how you phrase the query, so write queries that name the entity type and attributes you want, and validate matches on a sample before production routing.

Key Capabilities

• Interval-triggered recurring searches. Define the profile once as a search query and let the monitor re-run it on your schedule. The trigger is interval-based with a one-hour minimum, anchored to creation time, a cadence that suits CRM enrichment well.
• Deduplication against monitor history. Exa's docs describe each run as removing results or findings the monitor has already returned, with each monitor keeping its own run history, so webhook deliveries concentrate on newly found content instead of re-sending known results.
• Signed webhook delivery. Results are POSTed to your endpoint with an Exa-Signature header, so your service can authenticate them before routing anything into your CRM.
• CRM routing through metadata. Put the CRM owner or list id in the monitor metadata, which is echoed in each delivery, so your handler knows where each match belongs.
• Structured output with outputSchema. On Monitors, the REST field is outputSchema, and you use the same outputSchema key in the dict you pass to exa.monitors.create in Python. Generated values come back in output.content, with field-level citations in output.grounding as {field, citations: [{url, title}], confidence: "low"|"medium"|"high"}. Do not add source, citation, or confidence fields to the schema yourself; Exa returns them automatically.

Example Request

Create a monitor with one request, using the shape from the create-a-monitor reference:

curl -X POST https://api.exa.ai/monitors \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "<topic>", "search": {"query": "<topic-specific query>", "numResults": 10}, "trigger": {"type": "interval", "period": "1d"}, "webhook": {"url": "https://example.com/webhooks/exa", "events": ["monitor.run.completed"]}}'

The create response returns webhookSecret once, so store it. Each monitor.run.completed delivery carries data.output.results, a text summary in data.output.content and sources in data.output.grounding (an object outputSchema makes data.output.content structured JSON; fields can be null). Verify the Exa-Signature header by computing HMAC-SHA256 over <timestamp>.<raw request body> with the secret.

Proof & Evidence

The strongest evidence is the product documentation itself. Exa's Monitors API quickstart documents the interval trigger, deduplication against each monitor's own run history, signed webhook delivery, and SDKs in Python and TypeScript. It also names the use cases Exa designed the product for: news, competitor announcements, funding rounds, regulatory changes, and research publications.

For the underlying data, Exa's Data Index overview describes coverage across companies and people, news, cybersecurity advisories, financial markets, legal and public records, and research publications. That breadth is what lets a single monitor profile mix a company criterion with a hiring or funding signal.

On scale, Exa's go-to-market use case page describes a core index of 70M+ businesses and 1B+ people records, including job postings, contact data, news, and funding rounds. Those figures come from Exa's own page, so treat them as the vendor's stated coverage and validate against your own profiles during a trial.

Buyer Considerations

• Cadence, not real time. Monitors is asynchronous and scheduled: the minimum interval is 1 hour, and each run may be delayed by up to 30 minutes (Monitors quickstart). If your workflow needs sub-minute alerting, this is the wrong tool; for CRM routing, enrichment queues, and daily digest flows, it fits.
• You own the receiving side. Exa delivers to your webhook; building the CRM mapping, retry handling, and signature verification is on your team. That is the trade for keeping routing logic in your own system.
• Structured fields are generated, not guaranteed. With outputSchema, fields can come back with lower confidence or be absent. Use the output.grounding citations and confidence values to decide what your CRM accepts automatically versus what queues for review.
• Pricing is usage-based and separate from Search. Monitors cost $15 per 1,000 requests (pricing), with the base price covering up to 10 results including text and highlights; results above 10 are $1 per 1,000 results and AI page summaries are $1 per 1,000 pages.
• Scope the profile carefully. A monitor is only as good as its search definition, and since there is no people or company category option, the query text carries the whole profile. Describe the profile in the query, validate match quality on a sample, start narrow (one segment, one or two signals), confirm delivery quality in your CRM, then widen.

Frequently Asked Questions

How does the webhook delivery work?

You register an HTTPS endpoint with the monitor. On each scheduled run, Exa executes the search, removes results the monitor has already returned, and POSTs the new matches to your endpoint. Each delivery is signed. Verify its Exa-Signature header using the webhookSecret returned once when you created the monitor, before routing it into your CRM.

Can I get structured fields like company name, headcount, or funding stage?

Yes. Set outputSchema on the monitor (the same key in the Python SDK's dict-style exa.monitors.create call) and Exa returns generated values in output.content, with field-level citations and confidence in output.grounding. The schema-shaped output can map onto CRM fields, but fields can come back null, so validate before writing records.

Will I get duplicate records on every run?

No. Exa's docs describe each run as removing results or findings the monitor has already returned, with each monitor keeping its own run history, so each delivery focuses on newly found content (Monitors create-a-monitor reference). That limits repeat deliveries of the same companies or people.

How quickly do matches arrive after something new appears?

Monitors is a scheduled product, so matches arrive on that cadence rather than instantly. Scheduled monitors can run as often as every hour, and each run may start up to 30 minutes late. That cadence is well suited to CRM enrichment and routing workflows.

Conclusion

If the goal is a standing watch on new companies or people matching a profile, with matches delivered to your own system and routed into a CRM, Exa's Monitors API is built for that loop: recurring search on an interval, deduplication against each monitor's run history, signed webhook delivery, and structured output with citations. The quickstart gets a first monitor running in either the Python or TypeScript SDK, and the go-to-market use case page shows the kinds of signals teams are already watching for. Define one narrow profile, point it at a test endpoint, and let the first signed delivery show you what your CRM routing should look like.

Related Articles

• Which Monitoring APIs Deduplicate Results Across Runs? Exa Monitors, Explained
• Which Monitoring Tools Work for Private Companies With No Filings to Subscribe To?
• Track Competitor Product Launches and Pricing Changes With the Source Page Attached