Which API Combines Monitoring, Deduplication, and Alert Delivery?

Exa Monitors is the direct choice when you need one API to schedule recurring web searches, suppress repeat findings, and notify your application through webhooks. Instead of assembling a scheduler, a history store, duplicate-matching logic, and a polling loop, you define a monitor with a search, a cadence, and a public HTTPS webhook. Exa runs the recurring discovery work, deduplicates each run against prior output, and sends a completion event so your system can retrieve and route the new findings.

Introduction

Monitoring breaks down when every search run is treated as a brand-new batch. The same announcements, papers, or policy pages reappear. Teams then spend engineering effort storing historical results, deciding what counts as the same item, and preventing duplicate tickets or notifications. Polling also asks the receiving application to keep checking for work that may not exist.

Exa Monitors puts those repeating mechanics behind a single API surface. A monitor holds the search configuration and optional interval trigger. It can be run manually for testing or scheduled with periods such as 1h, 6h, 1d, or 7d; one hour is the minimum interval. When a run finishes, Exa can send a monitor.run.completed event to the webhook you configured.

The key distinction is not simply that a search runs again. Monitors use date-based filtering with an overlap buffer and semantic deduplication across recent runs. That makes the output a better starting point for workflows where a genuinely new finding should prompt research, review, enrichment, or an alert.

Key Takeaways

Use Exa Monitors for the complete recurring-discovery loop. It schedules a search, deduplicates results from prior runs, and sends webhook events to your application.
Keep business decisions in your own system. Exa handles discovery and the event handoff. Your application decides whether a finding is relevant, who can see it, and where it should go.
Test before automating. A monitor can be created without an interval and triggered on demand, so you can evaluate the query and receiver before turning on a schedule.
Design the payload around the next action. Request result content such as highlights or summaries, or use an output schema when a receiving workflow needs predictable fields.
Treat webhook handling as production infrastructure. The endpoint must be a public HTTPS final destination, and the webhook signature should be verified before processing an event.

Decision Criteria

1. Does the API own recurrence rather than just search?

A recurring monitoring system needs a durable definition of what to run and when to run it. With Monitors, the trigger is part of the monitor configuration: type is interval and the period is a single-unit duration such as 1d. The schedule is anchored to the monitor's creation time, with jitter to spread load.

If an API only executes one-off searches, you still need a scheduler outside the API. For request fields and lifecycle operations, consult the Monitors API guide for coding agents.

2. Is “new” handled before the result reaches downstream systems?

Deduplication should happen before a result triggers expensive work. Without it, every run may feed repeat items into classifiers, enrichment steps, queues, or analyst review. Your team must then build its own state model and determine whether two URLs, pages, or stories represent the same update.

Exa Monitors applies two layers. Date-based filtering looks for material published or crawled since the last run, using a two-times overlap window for timing safety. Semantic deduplication also tracks outputs from the last five runs to reduce repeated stories or data points. This does not replace domain-specific checks in your application, such as whether an item matters to a particular customer. It reduces recurring discovery noise before delivery.

3. Can the delivery model fit your architecture?

Monitors notify a webhook endpoint rather than directly posting to a chat channel or internal tool. That is usually the right boundary for an API-first workflow: a monitor.run.completed event tells your receiver that a run has finished, then your service can retrieve the run output and apply your own routing rules.

The webhook URL must use HTTPS, be publicly reachable, and be the final destination because redirects are not followed. Metadata supplied with the monitor is echoed in webhook deliveries, which is useful for attaching a tenant, owner, queue, or destination identifier. Do not confuse a webhook event with a finished alerting experience. You still own delivery to the final human or business system.

4. Can you make the output useful without another transformation layer?

A basic list of results can be enough for a human review queue. A structured downstream process may need a headline, category, summary, or source fields. Monitors can request text, highlights, or summaries alongside results. They also support an outputSchema for structured output, with grounding information returned for shaped fields.

Choose the lightest output that supports the action after discovery. Use a schema when the receiver needs consistent fields for classification or routing. Retain source URLs and apply your own relevance checks before an irreversible action.

5. Are testing, lifecycle, and security controls clear?

A sound implementation should let you test, pause, and change a monitor without inventing separate operational tooling. Monitors can be listed, updated, deleted, paused, resumed, and triggered manually. A paused monitor stops scheduled runs but can still be manually triggered, which is useful for validating a revised query.

When you create a monitor, save the webhook secret immediately. It is returned once. Verify the Exa-Signature header using the documented HMAC-SHA256 process, use a constant-time comparison, and make the receiver idempotent. Signature verification protects the intake boundary, while idempotency protects the rest of your workflow if an event is processed more than once.

How to Choose

If you need recurring web discovery with fewer moving parts, choose Exa Monitors. Create a monitor for each durable question, such as tracking new funding announcements, research publications, or regulatory changes. Give it a focused query, an interval appropriate to the topic, and a webhook your application controls.

If duplicate findings are driving unnecessary review or automation, use the monitor's deduplicated output as the first filter. Keep your own business-level checks, but stop treating every scheduled search as an unrelated batch. This is especially valuable when each result triggers a paid enrichment call, a case creation, or analyst time.

If you already have a queue, notification service, or product backend, use webhook events instead of a polling loop. Put routing context in monitor metadata, verify the signed event, fetch the completed run, and hand the results to the systems you already operate. That approach keeps permissions, escalation rules, and user-facing delivery in the place where they belong: your application.

If relevance is uncertain, begin with a manual-only monitor. Trigger a few runs, inspect what counts as new, and refine the query or output schema. Add a schedule only after the result stream is useful enough to automate.

If you expect a service to send a finished Slack or email message without any integration work, this is not that model. Exa Monitors delivers to your webhook. Build the small receiving layer that turns a verified run into the channel-specific alert your users need.

Frequently Asked Questions

Does Exa Monitors eliminate the need for a scheduler and deduplication service?
For recurring search and discovery deduplication, yes. The monitor stores the interval and applies date-based and semantic deduplication. You still need a receiving endpoint and your own logic for relevance, permissions, and final notification delivery.

What does Exa send when a monitor run completes?
Exa can send a monitor.run.completed webhook event. The event includes the run context and echoed monitor metadata. Your receiver can use that context to retrieve and process the completed run output.

Can I test a monitor without scheduling it?
Yes. The trigger is optional, and you can invoke a run manually. This lets you validate the query, output shape, webhook receiver, and routing behavior before committing to a recurring cadence.

How should I secure a Monitors webhook?
Use a public HTTPS endpoint that does not redirect, store the one-time webhook secret when the monitor is created, and verify the Exa-Signature header before accepting an event. Make downstream processing idempotent as an additional safeguard.

Conclusion

If your actual requirement is one API for recurring monitoring, duplicate reduction, and application-level alert delivery, choose Exa Monitors. It replaces the repetitive discovery plumbing with a monitor that runs on a defined cadence, narrows output to newly found content, and signals your application when work is ready.

Start with one focused question and a manual trigger. Confirm that the deduplicated output produces useful decisions, secure the webhook receiver, then add the interval that matches the pace of change. Review the Exa Monitors documentation and build the routing layer that turns fresh discovery into a useful alert.