Skip to main content
Reference material for Company Search: the full list of filter operators, searchable fields with sortable flags, response fields, validation rules, and error responses. For walk-through examples, see Company Search and Examples.
Pricing. Search bills 0.03 credits per result, plus a per-result charge for each premium group you filter on or receive. The premium families in the tables below are taxonomy, followers, headcount (including the roles filters), funding, hiring, software_reviews, maps, and the filter-only technographics fields. Prices are under Premium fields in search; your own are on /account/endpoints.

Pass a search object to rank companies against a natural-language query. search.query is required and must not be empty. search.mode controls which retrieval methods run. When you supply filters, the API applies them as hard constraints before keyword or semantic retrieval. Ranked results are ordered by relevance, so you cannot combine search with sorts. Ranked search returns up to 100 results per page and supports cursors across at most 1,000 candidate positions per search.

Filter operator reference

Company Search accepts the following filters.type operators.
The operators >= and <= are not supported. Use => and =< instead.

geo_distance — radius around headquarters

geo_distance keeps companies whose headquarters is within a radius of a point. All three geo operators work on the locations.headquarters field only. Supply the centre of the radius using one of:
  • location — a string that is geocoded server-side (e.g. "Palo Alto, CA").
  • lat_lng — explicit coordinates as [lat, lng]. Skips geocoding.
If both are supplied, lat_lng wins. distance is required; unit defaults to km. See geo_distance examples for end-to-end requests using both location and lat_lng.

geo_exclude — exclude a radius

geo_exclude is the inverse of geo_distance: it removes companies headquartered inside the radius and keeps everyone else. It takes the same value object — location or lat_lng, a required distance, and an optional unit (defaults to km) — and works on the same locations.headquarters field. Use it to carve out a metro you already cover, or to target companies outside a region.

geo_polygon: inside a polygon

geo_polygon keeps companies whose headquarters falls inside a polygon you draw with explicit coordinates. Use it when a radius is the wrong shape: a sales territory, a metro boundary, or an area you traced on a map. It works on the same locations.headquarters field as geo_distance. The polygon closes itself, so repeating the first point is optional. Edges may not cross, and no point may be revisited. Points are coordinates, not place names, and are not geocoded. A polygon that crosses the 180° meridian must list its points counter-clockwise, or it is read as everything outside it.
A polygon with fewer than 3 distinct points, a malformed pair, crossing edges, or an out-of-range coordinate returns 400 with a message naming the problem, for example geo_polygon 'points' needs at least 3 distinct points.

Searchable fields

These are common fields that can be used in the field key of a filter condition. Some indexed filter fields are search-only and are not returned in the response payload. For the full schema, see the API reference. Fields are grouped by family below. Every field listed is filterable; the Sortable column marks the subset also valid in sorts.

Identity & timestamps

Basic info

basic_info.status is the company’s lifecycle in Crustdata’s entity graph. It is the same value the person APIs return as company_status on an employment record. Two values are defined:
  • active: a live company record.
  • deleted: a record Crustdata has retired. Other records can still point at it, so you meet this value most often in a person’s employment history.
Company search serves the live company index, so a deleted company is not a result there. Filter basic_info.status when you want the check written into the query, and read it on the response to see the lifecycle of a company you already matched.

Revenue & funding

Headcount & roles

The headcount.growth_percent.* and headcount.growth_absolute.* dotted period paths are filterable but not sortable. To rank results by growth, filter on the period you care about and sort on headcount.total (or another sortable field). See Find high-growth mid-size companies.
Replace <function> with one of: accounting, administrative, arts_and_design, business_development, community_and_social_services, consulting, customer_success_and_support, education, engineering, entrepreneurship, finance, healthcare_services, human_resources, information_technology, legal, marketing, media_and_communication, military_and_protective_services, operations, product_management, program_and_project_management, purchasing, quality_assurance, real_estate, research, sales, support. For example, roles.distribution.engineering filters on the number of engineers. See Find companies by team size in a function.

Locations

Normalized location facets. locations.state and locations.city filter against and return normalized values derived from geocoding each company’s headquarters address — the value you see in a response is the value you filter with. locations.country accepts both vocabularies: ISO-3 codes ("USA", "GBR") and full country names ("United States") each match all companies, so existing ISO-3 filters keep working unchanged. Responses return the normalized full country name. Use Autocomplete to discover indexed values before filtering.

Taxonomy

Followers

Social profiles

Competitors (filter-only)

Technographics (filter-only)

Technographics values are not returned in search responses. These fields are filter-only. technographics.total_technologies is filterable and sortable, but it is not returned in results. technographics.top_technologies is filterable but likewise not returned. technographics.technologies.name is likewise not returned, and technographics.technologies.category and technographics.technologies.super_category are likewise not returned. To get the values, request the technographics field group on Company Enrich. Use Autocomplete with the technology and technology_category fields to discover valid filter values.
Use Autocomplete to discover exact values for fields like basic_info.industries, taxonomy.professional_network_industry, locations.country, basic_info.company_type, and funding.last_round_type.

Response fields

Each company in the response has crustdata_company_id, even when you do not request it. It can also include these sections, depending on fields. A section you request that has no data for the company is null.

Filterable but not returned

Some indexed fields can be used in filters to narrow results but are not part of the response payload — search is lightweight discovery, not full enrichment. Filter on them, then fetch their values with Company Enrich.

Validation rules

Default/max limits and pagination behavior reflect current platform behavior. See the API reference for the formal OpenAPI contract.
Filter sizing. To match many values of a field, put them all in a single in condition rather than many separate conditions — in compiles to one efficient query. A single in list of up to ~5,000-10,000 values returns in a few seconds; larger lists get progressively slower, and very large lists (roughly 50,000+) are rejected. For bigger sets, split the values into ~5,000-10,000 chunks across multiple requests and merge. The request body is hard-capped at 10 MB (larger bodies return 413 request_too_large), though with typical payloads you reach the query-size limit first.

Errors

Common error responses for Search:

Ranked cursor errors

A malformed or expired signed cursor returns HTTP 400:
Changing the query, mode, filters, or API version returns HTTP 400:
Restart without cursor after these errors. Do not retry the same invalid cursor.

Other search errors

400 — Unsupported field
400 — Invalid operator
Use => for greater-than-or-equal and =< for less-than-or-equal. The operators >= and <= are not supported.
401 — Invalid API key

API reference summary

How sorts work

The sorts parameter orders your results. Each sort rule needs:
  • column — a dot-path field (e.g., funding.total_investment_usd, headcount.total, basic_info.name).
  • order — either asc (ascending) or desc (descending).
You can provide multiple sort rules. The API applies them in order. For the full list of sortable fields, see Search reference. sorts is not supported with ranked search. Ranked results are ordered by relevance.

Paginate through results

Ranked pagination

For hybrid, lexical, and semantic search, pass the previous response’s next_cursor as cursor. Each page accepts limit from 1 to 100 (default 20). A search covers at most 1,000 candidate positions. total_count is always null; it does not report the candidate ceiling or the total matching population.
  • Keep search.query, search.mode, filters, and x-api-version unchanged.
  • You may change limit and authorized fields between pages.
  • Do not send sorts with ranked search.
  • Cursors expire 20 minutes after the initial search. Paging does not renew them.
  • The first 100 candidates are reranked. Later candidates use retrieval ranking without another reranking pass.
  • Candidate order is retained, but company records are read again for each page. Deleted companies or records that no longer satisfy filters are omitted and still consume their original positions. A short or empty page can have a cursor.
  • Continue until next_cursor is null. A cursor does not guarantee a nonempty next page.
  • If the cursor expires, cached results are unavailable, or the search index changes, restart without cursor.
See the worked request and response.

Filter-only pagination

When your search matches more companies than your limit, use cursor-based pagination to walk through all pages. First page: send your normal search request.
Next page: take the next_cursor value from the response and pass it in your next request. Keep the same filters, sorts, limit, and fields.
Continue until next_cursor is null, which means you have reached the last page.
Changing filters, sorts, or fields between pages invalidates the cursor. Always include sorts when paginating to guarantee stable ordering.
See the full API reference for the complete OpenAPI schema.