Filter by signal subtypes — OR within the array (a signal matching ANY value passes). CROSS-TYPE: the list applies across ALL requested signal_types; SEC filing types share content-tag subtypes, so e.g. {"signal_types":["sec-8k","sec-10k"],"signal_subtypes":["aiInvestment"]} is a first-class pattern. Values are matched case-insensitively against the known vocabulary (see the per-type subtypes array on GET /v1/signals/types?include_counts=true); unknown values fall back to exact match (0 results — never a 400). NOTE: subtype filtering on high-volume types (linkedin-post-, work-milestones, website-intelligence, twitter-, seo-traffic) caps the scanned window to the most recent 14 days (a notice is returned).

Filter to signals about these company domains (e.g., ["snowflake.com"]).

Filter by company industry.

FISH-892 — search inside the enriched content of social and podcast
signals. Think of it as: "give me the companies/people posting (or
talking) about X, and show me the posts." You get the deduped entity
with its matching signals attached.

Only supported for social + podcast signal types — the seven
social slugs: linkedin-post-company, linkedin-post-contact,
linkedin-comments-contact, twitter-company-posts,
twitter-contact-posts, youtube-company, youtube-contact — plus
the two podcast slugs: podcast-company, podcast-contact. If
content_filters is present and the request includes any other
signal_types, the API returns 400 invalid_request
(content_filters is only supported for social signal types); the
body lists both the allowed set and the offending types. (signal_types
itself is always required — a request without it is rejected at
validation, so there is no "typeless" content search.)

The five fields

Each field below is an independent contains / not_contains clause
(each capped at 20 terms, 1–500 chars per term — see
ContentFilterClause):

• keywords — substring (ILIKE), case-insensitive, across the
  union of post/comment/video text and summaries (post_text,
  comment_text, video_description, summary, comment_summary);
  for podcast types, the transcript-derived text (headline,
  evidence, quotes[], talking_points[].{point,quote},
  offer_texts[], topics[]). The fuzzy catch-all.
• tech_mentioned — exact (case-insensitive) match on the
  extracted technologies_mentioned[].name. Canonical names only:
  "Salesforce" matches, "Sales" does not.
• competitors_mentioned — exact (case-insensitive) match on
  the extracted competitors_mentioned[].name. Canonical names only.
• pain_points — substring (ILIKE) on the extracted
  pain_points[].topic.
• initiatives — substring (ILIKE) on the extracted
  initiatives[].topic.

Podcast caveat: podcast payloads carry only transcript-derived
text — none of the four extracted arrays — so keywords is the only
clause that matches podcast content; tech_mentioned,
competitors_mentioned, pain_points, and initiatives match social
types only and never match a podcast row. The same asymmetry governs
not_contains: pain_points.not_contains / initiatives.not_contains
exclude all podcast rows (the searched text is NULL for podcast,
and NOT (NULL ILIKE …) is not true — the same semantics as a social
row missing the field), while tech_mentioned.not_contains /
competitors_mentioned.not_contains keep podcast rows (an empty
array matches no excluded term).

Boolean logic

• Within a contains array → terms are OR'd (match ANY).
• not_contains → exclude the row if ANY term hits.
• Across the five fields → clauses are AND'd (a row must
  satisfy every field you specify).

Prefer the structured fields over free text when they fit your intent:
"companies mentioning Salesforce" → tech_mentioned: {contains: ["Salesforce"]} (exact + fast), not keywords: {contains: ["Salesforce"]}.

Performance

Structured clauses (tech_mentioned, competitors_mentioned,
pain_points, initiatives) run against indexed extracted fields and
are typically sub-second. The one thing that gets slow is a broad
free-text keywords search over a wide date window — a common word
matches an enormous number of posts and grouping them is the cost. To
stay fast:

• Keep keywords searches to a ≤ 30-day detected_after window.
  Social data refreshes on a biweekly (LinkedIn posts) /
  monthly (Twitter, YouTube, comments) cadence, so a 30-day window
  already contains everything fresh — scanning wider buys latency, not
  recency.
• Pair keywords with a selective clause — a tech_mentioned /
  competitors_mentioned clause or company_domains shrinks the
  candidate set first and makes even a wide window fast.
• Send fewer signal_types per call.

A broad query that still runs out of time returns 408 query_timeout
with tailored, ordered guidance (term names + fixes in
details.suggestions / details.broad_terms) — apply a suggestion and
retry; it is not charged. A 408 means "too broad," not "down." When the
SEARCH_REJECT_BROAD_KEYWORD flag is enabled (OFF by default), an
obviously-too-broad query is instead rejected up front with 422
query_too_broad carrying the same guidance body. A 200 with 0
results is normal for exact-match fields over sparse windows and
comes with an explanatory top-level hint.