Preview match frequency for an alert before creating it
Kicks off an asynchronous sweep over the past N days (default 7, max 30) and returns a preview_id. Poll GET /v1/alerts/preview/ until status is completed (or failed). The result includes the total match count, a per-day breakdown, and a small sample of the most-recent matches with full payload so the UI can show “if you create this alert, here’s what it would have caught.”
Authorizations
Pass your API key in the X-API-Key header (recommended).
Path Parameters
Project ID.
Query Parameters
Number of days back to sweep. Defaults to 7; capped at 30.
7
Body
Same as CreateAlertBody.entities.
1 - 100 elementsSame as CreateAlertBody.filters. Pass the filters you intend to save so the estimate reflects what the alert would actually surface. Only languages and speaker_roles narrow the historical sweep; relevance and source_popularity are read-time projections that don't run on historical episodes, so setting them leaves the count unchanged (the estimate is an upper bound when relevance=RELEVANT).
Same as CreateAlertBody.kind. Defaults to ENTITY_MENTION.
ENTITY_MENTION, PODCAST_SPEAKER Response
OK
Deterministic preview ID — repeating the same body within the TTL returns the same ID. Poll GET /v1/alerts/preview/{previewId} when status is 'in_progress'.
'in_progress' means a sweep is running (or was just started); 'completed' means an earlier identical preview is still cached and the result is ready to fetch via GET. A 'failed' prior preview is treated as a cache miss and a fresh sweep is started — callers never see 'failed' on this endpoint.
in_progress, completed