Skip to main content
Jarvi runs a full-text search engine over your data. Names, emails, phone numbers, job titles, skills and custom field values are indexed, and _search queries those indexes. Filtering with _ilike "%term%" does something else entirely: it walks every record in your workspace and compares it to the pattern. On a production base, a single _ilike on a last name was measured at 2.4 seconds; the same search through the index answers in a few tens of milliseconds.
_ilike, _like, _nilike and _nlike are being retired from the public API on 31 July 2027.On the REST endpoints you have nothing to do — _ilike filters are already translated into an indexed search on your behalf, and the response tells you which filter replaced yours. Through the /graphql endpoint the query is yours to change, since it can address any table.

Using the operator

A filter takes the name of a search target and a term:
Combine several with _and, _or and _not, as you would with any other filter:

Query syntax

The term itself is a query, not a plain string:

Whole words, not fragments

Names are indexed word by word, from the beginning: Dupo finds Dupont, upont does not. The same applies to company and project names. Emails and phone numbers are indexed differently and do match a fragment anywhere, so a phone number is found from its last digits, and an email from its domain.

Filters, resource by resource

Every filter below is index-backed. Any other Hasura column or relation is still accepted, but it is neither optimised nor guaranteed.

Profiles

Companies

Projects

These lists are generated from the search engine itself, so they are always what the API accepts. The same definitions are served as JSON Schema by GET /openapi, under ProfilesFilters, CompaniesFilters and ProjectsFilters.

Sorting

The orderBy parameter of each REST endpoint pairs one field with a direction:
The fields a resource accepts are listed in the parameter’s own documentation, on the endpoint page. Sorting on anything else falls back to the default order rather than failing.

Searching through GraphQL

The search query returns identifiers and a total, which you then load in a second call. Fetching in two steps is what keeps a search fast, whatever the size of the records:
resource is profiles, companies or projects. filters takes the same object as the REST where parameter.

Moving off _ilike

An identifier or a URL is never a search: match it with _eq, which uses its own index.
Something missing, or a filter you expected and did not find? Write to us — the list above is driven by the engine, so adding a filter to it is a small change.