Search companies (entity-aggregated)

post

https://signals.autobound.ai/v1/companies/search

Discover distinct companies that have one or more signals matching the filter, sorted by most-recent signal. Each result is a single company with its top-N signals attached (signals_per_entity, default 25).

Use this for ICP / audience-building workflows where you want a list of unique companies rather than a flat list of signals.

content_filters (social search)

Pass content_filters to search inside the enriched content of social posts (the seven social signal types only — see ContentFilters). Structured clauses (tech_mentioned, competitors_mentioned, pain_points, initiatives) are exact/fast (typically sub-second); broad free-text keywords over a wide window is the one thing that can be slow.

Self-service responses

408 query_timeout (default, always on): a broad content search that runs out of time returns tailored guidance — message names the broad term(s) and lists ordered fixes, with details.suggestions / details.broad_terms. Apply a suggestion and retry; not charged.
422 query_too_broad (OFF by default, behind SEARCH_REJECT_BROAD_KEYWORD): when enabled, an obviously-too-broad query is rejected up front with the same guidance body instead of grinding into a 408.
hint (on a 200 with 0 results from a content_filters search): an optional top-level string explaining the likely cause (e.g. exact-match fields need canonical names like "Salesforce", not "Sales"; or widen detected_after).
notice (on a 200 when an entity filter is applied): an optional top-level string noting results were limited to the most recent 14 days (see the detected_after 14-day cap).

Credit cost: 2 per company returned.

Recent Requests

Time	Status	User Agent
Retrieving recent requests…

Loading…

Body Params

Filters for entity-aggregated company search. At least one signal_types value is required.

signal_types

array of objects

required

length ≥ 1

signal_types*

signal_subtype

string

detected_after

date-time

ISO-8601 lower bound. Defaults to 30 days ago when omitted (bounds the GROUP BY scan; pass an older value to query further back). NOTE: when the request includes an entity filter (industries, employee_count_min/max, seniority, department, or job_title), the scanned window is capped to the most recent 14 days. A wider detected_after is narrowed to a 14-day slice ending at NOW (or, when detected_before is supplied, ending at detected_before). This is a temporary safeguard against statement timeouts on high-volume signal types; unfiltered (type-only) searches are not affected.

detected_before

date-time

limit

integer

1 to 100

Defaults to 20

offset

integer

0 to 10000

Defaults to 0

signals_per_entity

integer

1 to 100

Defaults to 25

How many of each company's most-recent signals to attach.

company_domains

array of strings

length ≤ 100

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

company_domains

company_domain

string

length ≤ 253

Singular alias for company_domains.

industries

array of strings

length ≤ 50

Filter by company industry.

industries

employee_count_min

integer

≥ 0

Minimum company employee count.

employee_count_max

integer

≥ 0

Maximum company employee count.

content_filters

object

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

Only supported for social 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. If content_filters is present and the request includes any non-social 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.

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). 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.

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.

Responses

The five fields

Boolean logic

Performance

200Aggregated companies

400Invalid request parameters

401Missing or invalid API key

402Credit balance exhausted. Under the running-balance model there is no monthly limit or billing-period reset — the account simply has a zero balance and must be topped up.

429Rate limit exceeded

500Internal server error