Documentation

Search syntax

The syntax is small. One habit accounts for most of the difference between clean results and noise.

Quote what you mean as a phrase

Bare space-separated terms are ANDed, and each may match anywhere in the document. On a two-hour transcript that is a real problem: comfort food matches an episode that says "comfort" in the intro and "food" an hour later, about nothing related.

comfort food        # both words, anywhere, possibly an hour apart
"comfort food"      # the actual phrase

On long-form content this is usually the whole difference. Quote brand names, product names and anything that is really one idea.

Operators

SyntaxDoes
"exact phrase"Matches that word sequence.
AND OR NOTCombine terms. Uppercase only — lowercase and is treated as an ordinary word.
( )Group.
field:valueScope to title, body, transcript or author.
"Acme Corp" OR "acme.com"
"Acme" AND (pricing OR funding OR "series b")
"Acme" NOT "acme paints"
author:altman

A bare term searches title, body and transcript together. Malformed syntax — an unbalanced quote, a dangling operator — is repaired rather than rejected, so a query never fails just because a model wrote it slightly wrong.

Use the parameters, not the query, for filters

You can write source_type:podcast into q and it works. Prefer the parameter:

?q=%22Acme%22&source_type=podcast&has_transcript=true&window=month

Parameters are validated, so a typo is a 422 telling you what is wrong rather than a query that silently matches nothing. Everything you can filter on is in the endpoint reference.

Ranking

sort=relevance (the default) puts the most on-topic first. sort=recency gives you a chronological stream — the right choice for "what has been said this week", where you want the order to be time rather than a score.

Windows

window takes 24h, 48h, week, month, 3months, year or all. These are rolling windows measured back from right now, not calendar periodsmonth means the last thirty-odd days, not the current calendar month.

Writing a query for an alert

Test it as a search first. An alert query that is too broad is worse than one that is too narrow: a stream of irrelevant hits gets muted, and then the relevant one gets missed too. See Your first alert.