Skip to main content
Most fields on this API take a plain string or an array of them. That is deliberate — the vocabularies behind them are large and change over time — but it means the schema alone rarely tells you what to send.
For most filter and agent-config fields, a value outside the accepted vocabulary is not rejected. The call succeeds, and the search or agent then matches nothing. There is no error to debug, so it is worth resolving values before you send them.
Every field in the API reference says which of the four cases below it falls into. This page is the general rule.

​
1. The value is in the schema

If a field has a fixed, short vocabulary, the values are on the schema itself and a generated client types them as a union. Sending anything else is a clean 422. channel, entityType, searchPeriod, eventType, sortOrder and about 150 other fields work this way.

​
2. An endpoint serves the vocabulary

Large or changing vocabularies live behind a lookup. The field description names the exact call, including which key of the response to read. Resolve first, then send the exact string you got back:
A lookup serves specific fields, not everything that looks similar. field=region returns geographies including sub-national areas such as "California, United States" — useful for a regions filter, wrong for a country filter that only accepts "United States".

​
3. The values are listed in the description

Where a vocabulary is fixed but too long for an enum, or is defined by an upstream provider, the field description lists it outright. Headcount bands, funding round types, departments and timeframes all work this way:
Send the label exactly as written. A near-miss is usually accepted and then matches nothing — and some are worse than that: on list row filters, "51 to 200" is parsed with parseInt and narrows to companies with exactly 51 employees rather than being ignored.

​
4. It is free text

Some fields have no vocabulary at all — a web monitor prompt, post keywords, a smart column prompt. The description says so explicitly. Send whatever you like; the wording is what drives the match.

​
How several values combine

Every array field states how its values combine and any cap. Most are OR-joined — a row matches when any one value matches — but not all, and the caps differ:
Two behaviours are worth knowing because they surprise people:
  • Some arrays reject duplicates outright. Agent keywords and watcher listIds carry a uniqueness rule, so sending the same value twice is a 422, not a silently collapsed list.
  • A filter whose values all fail to parse does not become inert. On list rows it matches nothing and you get zero rows — which looks like “no results” rather than “bad filter”.

​
Checking your work

The quickest way to tell a bad value from a genuinely empty result is to run the same call twice, once without the filter: