Free-text search across every candidate in the company, served by the same search index that powers in-app candidate search. This verb always returns the paginated envelope below - one request contract, one response contract.

email_address is not accepted here and returns 400. Exact email lookup is the GET form of this path: it is served from the primary store and is immediately consistent, whereas this search is index-backed and eventually consistent, so a candidate created moments ago may not appear yet.

Access: results follow the caller. A company admin searches the whole company; any other token owner is limited to the positions they are a member of - the same scope in-app search applies to that user.

Query grammar: bare terms, quoted phrases ("product manager"), the boolean operators AND, OR and NOT, and a trailing * for prefix matching. With match: prefix (the default) the trailing wildcard is added for you, which is what the in-app search box does. Anything else that carries query-syntax meaning - field:value, regex delimiters, grouping, +, -, &, | - is searched as literal text, so a URL or a term like C++ matches as typed. A leading wildcard, an unbalanced quote, or a query starting or ending with a boolean operator returns 400.

Coverage: the index spans candidate name, email address, phone number, headline, tags, free-text and choice questionnaire responses, work history, education, and the position location. It does not cover uploaded resume or CV file contents, and it does not cover social profiles.

Results are position-scoped: a candidate record is a person on a position, so the same person appears once per matching position and total counts records, not people. meta_id is the stable person identifier if you need to group them yourself.