Search inside the enriched content of social signals.
Only supported for social signal types: linkedin-post-company, linkedin-post-contact, linkedin-comments-contact, twitter-company-posts, twitter-contact-posts, youtube-company, youtube-contact. Including any non-social signal_type with content_filters returns 400 invalid_request (the body lists allowed_signal_types and invalid_signal_types).
Each of the five fields below is an independent contains / not_contains clause. Within a clause's array, terms are OR'd; across the five fields, clauses are AND'd (every specified field must hold).
Matching per field:
keywords - substring (ILIKE) over the union of post/comment/video text + summaries (post_text, comment_text, video_description, summary, comment_summary).
tech_mentioned / competitors_mentioned - exact (case-insensitive) match on the extracted entity name; use canonical names ('Salesforce', not 'Sales').
pain_points / initiatives - substring on the extracted topic.
Performance. content_filters is served from a dedicated indexed search table, so the structured fields (tech_mentioned, competitors_mentioned, pain_points, initiatives) are sub-second at any window. The one slow path is a broad free-text keywords search: a very common term over a wide date window can scan too many posts and return 408 query_timeout. For fast, reliable keyword search, prefer specific multi-word phrases, pair keywords with a structured clause (tech_mentioned/competitors_mentioned) or company_domains, or keep the date window tight. A 408 returns details.suggestions + details.broad_terms you can retry against; an empty 200 may include a hint. Social data refreshes biweekly (LinkedIn posts) / monthly (other sources), so a tight recent window already captures the freshest batch.
Limits: max 20 terms per contains/not_contains array, each term 1-500 chars.