Skip to main content

Two scopes, one analytics surface

Every analytical endpoint in the Intel API runs against a scope. There are two kinds, and both expose the same surface — the only thing that changes is the path prefix. Both expose trending, volume, volume-by-keyword, narrative, entities, platforms, posts, and alerts. Cluster analytics on watchlists require Know. A useful mental model: a curated topic is a slice Exorde already runs at scale with a learned 14-day baseline; a watchlist is the same machinery pointed at terms you define. Same code path, same envelope shape, same ranking math.

Curated topics

The four public curated topics:
Additional curated slices (defense, energy, geopolitics, MENA, ai_tech, named-entity slices) are available to enterprise Know customers on request — email [email protected] with the desired scope.
Topic access is scoped per key. GET /v1/me returns your topics array. A Watch-tier trial is scoped to global only.
If you call a topic your key isn’t scoped for, you get 403 topic_denied. The error envelope tells you which topics you do have:

Listing topics


Analytics endpoints on curated topics

The full surface, by tier. Concept pages cover the response envelopes in depth. Hitting an endpoint above your tier returns 403 upgrade_required with current_tier, required_tier, and feature in the envelope. See Errors.

Custom watchlists

Watchlists are your private scopes. You define the terms; the API runs the same analytics against the matching post stream.

Term types

Mixed-type watchlists work and are common. A brand watchlist typically combines keyword (brand name + variants), domain (corporate sites), and entity (key executives). A threat-intel watchlist combines entity (named threat actors) and keyword (CVE families, malware names).

Create a watchlist

base_topic defines the universe the watchlist filters from. global matches the broadest stream; cyber filters to cybersecurity-tagged posts only. Most brand watchlists base on global; most threat-intel watchlists base on cyber.

Query a watchlist

The full analytics surface mirrors topic endpoints, with /watchlists/{id}/... instead of /topics/{topic}/.... Same JSON shapes, same tier gates.
A trending response on a watchlist:
Identical envelope to /topics/{t}/trending, with watchlist_id + name swapping in for topic. Code written for one works on the other.

Update or delete

PATCH on terms is whole-array replacement, not a delta. Send the full intended term list; anything missing from the new array is removed.

Limits and validation

Hitting a cap returns a typed envelope:
Validation errors at create/patch time: Full list: Errors.

Webhooks (push delivery)

See and Know tiers can register webhook URLs to receive alerts and watchlist signals as they fire, instead of polling.
Webhook payloads carry the same JSON shape as the corresponding poll endpoint, plus a delivery_id for dedup and an HMAC-SHA256 signature in the X-Exorde-Signature header for verification. Full setup, signature verification, and dedup pattern: Alerts → Webhook delivery.

When to use which

  • Use a curated topic when your use case aligns with one of the four public slices. Less setup, same analytics, baselines already learned over months of data.
  • Use a watchlist for anything outside the curated slices — a specific brand, actor, campaign, domain, or niche.
  • Combine both. A common pattern: poll /v1/topics/cyber/alerts for industry-wide signals and maintain a watchlist scoped to your own brand for company-specific monitoring.
  • Know-tier customers can request private curated topics — a topic that behaves like cyber or finance but is exclusive to your account, with bespoke baselines and audience-tuned narrative voice. Email [email protected] with the desired scope.
Last reviewed: 2026-05-19. API version 1.2.8.