Search People
Find people by their attributes, using a boolean rule tree.
Searches the same pool the list endpoint serves (your workspace’s people plus the platform library), and returns the same paginated envelope.
The rule tree
A rule is a single node. A node is either a leaf or a group, never both:
- A leaf tests one attribute:
{"field": {"source": ..., "key": ...}, "operator": ..., "value": ...}. Copysourceandkeyfrom the attribute’sfilterblock inGET .../people/schema; that endpoint is the authoritative vocabulary, and an attribute or operator it does not list is refused with a422rather than matching nothing. - A group combines nodes:
{"op": "and" | "or" | "not", "conditions": [...]}.
Boolean semantics, exactly
A group’s op applies to its OWN conditions and to nothing else. and
matches a person satisfying every condition in that group; or matches
a person satisfying at least one; not takes exactly one condition
and matches people who do not satisfy it. Groups nest, so a group inside
another group is evaluated on its own first and its result is then one
input to the parent’s operator. There is no precedence to remember and no
implicit combination anywhere: two conditions are only ever joined by the
op of the group holding them.
A worked example
“Nurses in Sweden, plus teachers in Norway” is two AND-groups joined by an
OR. Note that the country is repeated in both groups: the outer or does
not distribute over anything, so a condition placed outside the groups
would not apply to either.
{
"rule": {
"op": "or",
"conditions": [
{"op": "and", "conditions": [
{"field": {"source": "demographic", "key": "occupation"},
"operator": "eq", "value": "nurse"},
{"field": {"source": "demographic", "key": "country"},
"operator": "eq", "value": "Sweden"}
]},
{"op": "and", "conditions": [
{"field": {"source": "demographic", "key": "occupation"},
"operator": "eq", "value": "teacher"},
{"field": {"source": "demographic", "key": "country"},
"operator": "eq", "value": "Norway"}
]}
]
},
"pagination": {"limit": 25}
}
Testing whether an attribute is set
is_not_null matches people who have a value for an attribute, and
is_null matches people who do not. Reach for these rather than comparing
against an empty string: an attribute nobody filled in holds no value at
all, and it satisfies no ordinary comparison, not even a negated one.
Limits, and how a rule is refused
A rule may nest groups at most 2 levels deep, hold at most 15 conditions in any one group, and 25 in total.
Both refusals are a 422 carrying an error_kind, and they have different
fixes:
search_rule_too_complex: past one of those caps. The detail names the offending count and the limit. Combining values withincosts one condition instead of one per value, and is the usual fix.search_rule_invalid: the tree is malformed, or it names an attribute, source or operator this API does not publish. The detail names the offender, andGET .../people/schemais the vocabulary it was checked against.
A malformed request BODY (rather than a bad rule) is the ordinary
validation 422 with the field-level envelope, which is why this
operation’s 422 documents either shape.
Saved segments
Segments live in the ish app and are not exposed here. A segment IS a rule,
so the way to use one is to send its rule as the rule on this request:
that is how the ish console itself applies them.
Authorizations
Workspace API key as a bearer token: Authorization: Bearer ish_sk_live_.... Keys are workspace-scoped machine principals minted in Settings > Developers (shown once at mint). Scopes: sessions:run (create a session, submit turns, close), sessions:read (read the session and its decision trace), environments:read and environments:write (manage the workspace's registered environments), tasks:read and tasks:write (manage the workspace's registered tasks), people:read and people:write (the people the workspace can run a session for), and usage:read (the workspace's own consumption, spend limits and rate-limit budgets). A key is minted with sessions:run, sessions:read, and tasks:read by default; every other scope must be requested, people:read and usage:read included. An ish user access token also works on the same header for personal scripts.
Path Parameters
Body
A capped rule-tree query over the workspace's reachable people.
Unknown keys are rejected rather than ignored: a typo in a filter that silently widened the result set would be indistinguishable from a match.
false (the default) searches live people; true searches the archive instead. The two sets are disjoint, so this selects which one you are searching rather than widening the search.
Restrict to the people one generation job produced. Reads its own writes: a person is visible here the moment the job records them.
Restrict to one owner. Omitted returns both, which is the set you can open a session for.
self, platform Keyset pagination, in the body because the query is.
A boolean tree of filters. See the endpoint description for the grammar, the caps, and a worked example.
Case-insensitive substring match on the person's name.
200Response
Successful Response
A keyset-paginated page of people.
Ordered created_at DESC, id DESC, the same order and the same envelope
as the session list, so one pagination helper in an SDK drives both.