Monitor Web Mentions of Your Product or API and Route Them into Slack with Exa Monitors

Set up a recurring web search with the Exa Monitors API, point its webhook at a small handler that posts to Slack, and every newly found mention of your product or API arrives in a Slack channel automatically. Exa handles scheduling, time-based filtering, and deduplication against each monitor's own run history, so you write only the routing code.

Introduction

If you ship a product or an API, you want to know when someone writes about it: a developer blog comparing tools, a changelog mention, a forum thread, a security advisory touching your dependencies. Polling search engines manually does not scale, and building your own crawler means maintaining fetch queues, parsing, and state storage forever.

The cleaner path is to treat recurring search as a managed primitive. Exa's Monitors API quickstart describes exactly this pattern: you define a search, set an interval trigger, and Exa runs it on schedule, filters by time, removes results the monitor has already returned, and delivers only new findings to your webhook as signed deliveries so you can verify authenticity. From there, routing into Slack is a few lines of code. This article walks through the architecture, the capabilities that matter, and what to weigh before you commit.

Key Takeaways

• Exa Monitors is an API for scheduling recurring searches and delivering results to a webhook. Each run filters by time and removes results the monitor has already returned, so deliveries focus on newly found content.
• A webhook handler that verifies each delivery's Exa-Signature header and posts to Slack's chat.postMessage API completes the pipeline in a small amount of code.
• SDKs in Python and TypeScript make setup a quickstart-level task rather than an integration project.
• Exa names use cases including news, competitor announcements, funding rounds, regulatory changes, and research publications, and its index spans code, docs, and cybersecurity (CVE/GHSA) data alongside general web content.
• You control the query, the interval, and the destination, so the same primitive works for brand mentions, changelog watching, or advisory tracking, at $15 per 1,000 requests, plus $1 per 1,000 results above 10 and $1 per 1,000 AI page summaries (Exa pricing).

Why This Solution Fits

The question "who is talking about my product?" is fundamentally a recurring search problem, and recurring search is precisely what Monitors is built for. Instead of running a scheduler, a crawler, a deduplication store, and a delivery queue, you register a monitor and Exa handles the loop. On each run, Exa executes the configured search, filters by time, and removes results the monitor has already returned, so your webhook only receives newly found content rather than the same pages on every run.

That matters for Slack specifically. A channel that fills with duplicate links trains your team to ignore it. Because deduplication happens before delivery, each notification is a result the monitor has not already returned, which keeps the channel high-signal.

It also fits the engineering workflow. Exa's index covers code and documentation changes as well as cybersecurity data such as CVE and GHSA advisories (see the Data Index), so the same monitor that catches blog mentions can watch for advisories affecting your dependencies. And because delivery is a plain signed webhook, Slack is just one destination: the same handler could post to PagerDuty, email, or an internal queue.

Key Capabilities

Recurring search on an interval trigger. You define the query once and Exa runs it on your chosen schedule. The trigger is interval-based with a minimum of one hour, anchored to creation time, so you can schedule checks as often as hourly. The Monitors API quickstart shows the setup end to end with SDKs in Python and TypeScript.

Time filtering plus deduplication against run history. Each run filters by time and removes results the monitor has already returned, and each monitor keeps its own run history. This is the difference between a usable alert channel and noise.

Signed webhook delivery. Deliveries arrive at your public HTTPS endpoint signed with an Exa-Signature header. Verify it with the webhookSecret returned once at monitor creation, so your handler can confirm that a request genuinely came from Exa before posting anything to Slack. The endpoint must be the final destination, because redirects are not followed.

Slack routing through metadata. Store slack_channel_id / slack_thread_id in the monitor metadata, which is echoed in every webhook delivery. Exa does not post to Slack directly, so your handler uses those identifiers to post to the right place (see the "Receive webhook updates" section of the Monitors API quickstart).

Structured output. Monitors return a text summary in output.content and grounding sources in output.grounding by default. Use an object outputSchema for structured JSON, with field-level citations in output.grounding. That means your Slack message can include a short structured summary and a link rather than a raw blob.

Broad, categorized coverage. Exa's index spans news, companies and people, research publications, financial data, legal and public records, cybersecurity advisories, and code and docs. For mention monitoring, write the product name and context into the query and use includeDomains/excludeDomains to focus sources.

Example Setup

Create the 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 the run's results in output.results, a text summary in output.content and sources in output.grounding (an object output schema turns output.content into structured JSON; fields can be null). Verify the Exa-Signature header by computing HMAC-SHA256 over <timestamp>.<raw request body> with the secret.

For the Slack side, add "metadata": {"slack_channel_id": "<channel id>"} to the request body. Here is a handler sketch that verifies the signature, iterates the delivered results, and posts each url and title to Slack through chat.postMessage using the channel from metadata:

import hashlib, hmac, os, requests
from flask import Flask, request

app = Flask(__name__)

@app.post("/webhooks/exa")
def exa_webhook():
    body = request.get_data()
    sig = dict(p.split("=", 1) for p in request.headers["Exa-Signature"].split(","))
    expected = hmac.new(os.environ["EXA_WEBHOOK_SECRET"].encode(), sig["t"].encode() + b"." + body, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, sig["v1"]):
        return "invalid signature", 401
    data = request.get_json()["data"]
    for r in data["output"]["results"]:
        requests.post("https://slack.com/api/chat.postMessage", headers={"Authorization": "Bearer " + os.environ["SLACK_BOT_TOKEN"]}, json={"channel": data["metadata"]["slack_channel_id"], "text": f"{r['title']}: {r['url']}"})
    return "", 200

Proof & Evidence

Exa's Monitors API quickstart walks through creating a monitor with an interval trigger, deduplication against each monitor's own run history, and signed webhook delivery. Exa names the intended use cases directly: news, competitor announcements, funding rounds, regulatory changes, and research publications.

For coverage claims, the Data Index overview describes the underlying categories, including code and docs ingestion and cybersecurity (CVE/GHSA) data.

The Slack half of the pipeline needs no proof at all: it is a standard HTTPS POST to Slack's documented chat.postMessage API, which you can test with curl before wiring it into your handler.

Buyer Considerations

Before you build, weigh a few practical points:

• Query quality drives signal quality. Start narrow (your product name plus likely misspellings) and expand once you see what the noise floor looks like.
• Interval versus urgency. Recurring search is not real-time streaming. The minimum interval is 1 hour, and runs are asynchronous, with each scheduled run potentially delayed by up to 30 minutes (Monitors API quickstart). Choose an interval that matches how fast your team actually needs to react; Monitors fits mentions that can wait an hour or more.
• Webhook ownership. You need a small always-on public HTTPS endpoint (a serverless function works fine) that verifies the Exa-Signature header and forwards to Slack. If you have no backend at all, factor in that hosting step.
• Deduplication scope. Each monitor keeps its own run history, so deduplication is per monitor. If two monitors overlap in scope, you may see the same page twice across monitors; keep monitor scopes distinct.
• Cost model. Monitors cost $15 per 1,000 requests, plus $1 per 1,000 results above 10 and $1 per 1,000 AI page summaries, published on Exa's pricing docs; check current rates directly rather than assuming Search pricing applies, since each product is priced separately.

Frequently Asked Questions

Do I need my own crawler or scraper?

No. Exa Monitors runs the recurring search against its index and delivers results to your webhook. Your only job is a small handler that receives deliveries and posts to Slack.

How do I stop the same mention from appearing in Slack repeatedly?

You do not have to build this yourself. Each run filters by time and removes results the monitor has already returned, so webhook deliveries focus on newly found content, as the Monitors API quickstart describes.

Can I get structured summaries instead of raw pages?

Yes. Monitors return a text summary and grounding sources by default. Use an object outputSchema for structured JSON with field-level citations, so your Slack message can show a concise, sourced summary.

What else can I route the results to besides Slack?

Anything that accepts an HTTP call. Because delivery is a standard signed webhook, the same handler can post to PagerDuty, email, a ticketing system, or an internal queue. Slack is simply the most common first destination.

Conclusion

Monitoring the web for mentions of your product or API does not require building scraping infrastructure. Define a monitor with Exa Monitors, let it handle scheduling, time filtering, deduplication, and signed webhook delivery, and connect a short handler that posts each new finding to Slack. Start with the Monitors API quickstart, create one narrow monitor for your product name, and you can have your first mention alert in a Slack channel the same afternoon.

Related Articles

• Which Monitoring APIs Deduplicate Results Across Runs? Exa Monitors, Explained
• Web Monitoring APIs With Predictable Pricing at Scale: Why Exa Monitors Bills by Usage, Not by Seat
• Which APIs Let You Schedule a Recurring Web Search and Only Get Notified About New Results?