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
| Syntax | Does |
|---|---|
"exact phrase" | Matches that word sequence. |
AND OR NOT | Combine terms. Uppercase only — lowercase and is treated as an ordinary word. |
( ) | Group. |
field:value | Scope 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 periods — month
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.