Skip to main content
Agents & LLMs: a Markdown version of this page is available by appending .md to the URL, and the full documentation index is at llms.txt.
BlitzAPI Search endpoints (Company Search, Employee Finder, Find People, Waterfall ICP) use normalized values for categorical filters. Passing a value outside the accepted list (e.g., "SaaS" instead of "Software Development") returns a 422 that names the field and, when a valid value is close, suggests it. A 422 uses no records. Free-text filters such as country_code, city, job_title, and keywords are not checked against a list, so a wrong value there returns 0 results instead of an error. The exception is a country_code of the wrong length, which some endpoints reject with a 422 (see Country Codes).
All enum values are case-sensitive and must match exactly, except industries, which ignore case and also accept other known spellings of a label. Copy-paste from the linked pages to avoid typos.

​
Sections

This reference is split across the following pages so each is small enough to load fast and easy to copy from:

Keyword Filters

include / exclude keyword search behavior, exact-match brackets, and the visual diagram of how branches and exclusions combine.

Industry

The full list of 534 accepted industry values for company.industry.include and company.industry.exclude.

Job Levels & Functions

people.job_level enum (C-Team, VP, Director, …) and the 22-value people.job_function enum.

Companies

company.type and employee_range enums, NAICS / SIC code references, units for revenue, web_traffic, and ad_spend, the funding filters (last_funding_type values, total_funding, lead_investors), and the 66 mx.provider mail provider values.

Geography

Sales regions, continents, and country codes (ISO 3166-1 alpha-2) for location filters.

LinkedIn URLs

Supported LinkedIn URL and URN formats for people and companies, plus the people URL formats that are not supported.

​
Troubleshooting

The most common cause is a wrong value in a free-text filter such as country_code, city, job_title, or keywords. These are not checked against a list, so a wrong value returns 0 results instead of an error. The usual one:
  • Country code: "USA" is not valid, use "US". "United Kingdom" is not valid, use "GB". Depending on the endpoint, a wrong code returns 0 results or, when its length is wrong, a 422.
See Geography for every accepted country code and the length each endpoint checks.
A value outside an accepted list, or a field the endpoint does not define, returns a 422 instead of results. Each item in errors gives the field to fix and a message with the closest valid value. Common causes:
  • Industry: "Tech" is not valid, use "Information Technology and Services" or "Computer Software" or "Internet".
  • Employee range: "50-200" is not valid, use "51-200".
  • Job level: "vp" is not valid, use "VP". "C-Level" is not valid, use "C-Team".
  • Job function: "Sales" is not valid, use "Sales & Business Development".
  • Sales region: "NA" is not valid, use "NORAM".
  • Field name: "includes" is not a field, use "include".
All values are case-sensitive, except industries. Copy-paste from the linked pages.
The industry taxonomy is granular. Try using multiple values in your industry.include array to broaden the search. For example, instead of just "Computer Software", also include "Information Technology and Services" and "Internet".
Check that you’re using the right combination of job_level and job_function. For example, to find senior sales leaders, use "job_level": ["C-Team", "VP", "Director"] combined with "job_function": ["Sales & Business Development"].
If the request succeeds but returns nothing:
  • Make sure at least one of company or people is provided.
  • Avoid over-filtering: combining a narrow industry, a small employee_range bucket, and a strict hq.country_code will quickly empty the result set.
  • For person geography, set people.location.country_code, not company.hq.country_code. The two are independent filters.
Find People uses cursor-based pagination (not page-based). Pass the cursor value from the previous response back into the next request and stop when the API returns cursor: null. Do not assume total_results / max_results. Use the cursor as the source of truth.