Concept

Search and filtering

Events are filtered with conditions: 11 fields, 6 operators, joined with AND and OR.

Conditions

A condition is a field, an operator and a value. A list of conditions is applied left to right, and each one after the first says how it joins the ones before it.

Filterable fields

Field	Value
`Organisation`	An organisation reference. Get one with resolve_search_terms.
`Profile`	A person reference. Get one with search_people.
`Occupation`	A job title reference. Get one with resolve_search_terms.
`MoveType`	One of the move types.
`EventType`	One of the event types.
`CompensationType`	One of the compensation types.
`PublishedDate`	A date as `YYYY-MM-DD`. The only field that takes `>`, `<`, `>=` and `<=`.
`Industry`	A GICS code. Child codes match too, so `10` covers `1010` and `101010`.
`DealStatus`	One of the deal statuses.
`DealType`	One of the deal types.
`Jurisdiction`	A jurisdiction as recorded on the deal, such as `US` or `UK`.

Operators

EQUAL, NOT EQUAL, >, <, >=, <=. Ordering comparisons (>, <, >=, <=) only apply to PublishedDate. On any other field they're rejected.

Precedence

Conditions combine with SQL precedence, so AND binds tighter than OR. A AND B OR C reads as (A AND B) OR C. The filtering guide works through examples.

Invalid conditions are refused

An unknown field, an operator the field doesn't support, or a value outside the allowed list is rejected with a message naming the condition. A result set always matches every condition you gave.

Plan history windows

Some plans include a recent window of event history rather than the full archive. search_events states the window that applied in every response, so an empty result is never mistaken for a quiet period. See limits.