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.

Filter by company industry.

Filter by contact seniority. Canonical values (case-insensitive): "Staff", "Manager", "Director", "Vp", "Cxo". For accounts with enrichment-backed matching enabled, this filter resolves against the contact enrichment record (strict match), and unrecognized values return HTTP 400 with the list of valid values.

Filter by contact department. Canonical values (case-insensitive): "Administrative", "Community And Social Services", "Education", "Engineering", "Executive", "Finance", "Government", "Health Services", "Human Resources", "Information Technology", "Legal", "Marketing", "Media And Communications", "Military And Protective Services", "Operations", "Product Management", "Real Estate", "Sales". For accounts with enrichment-backed matching enabled, this filter resolves against the contact enrichment record (strict match), and unrecognized values return HTTP 400 with the list of valid values.

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.