Skip to main content

Global search — worked samples

One POST replaces the N parallel per-surface searches a client would otherwise fan out itself: the query is multiplexed against every product pillar in a single request, and the response comes back ranked across all of them. This is the endpoint behind the dashboard’s global search palette — use it the same way when building a custom search widget.

Request fields

Multi-pillar query across all seven pillars

200

Reading the response

Each entry in results[] — and in the per-pillar buckets under by_pillar — carries:
  • id — the entity’s own id, so client-render keys stay stable.
  • pillar — one of the seven pillar buckets above; drives the icon and group heading.
  • title — the headline label (a contact name, an agent name, a number).
  • subtitle — an optional muted secondary label (for a contact, the email or phone).
  • href — a locale-relative dashboard path; prepend /${locale} before navigating.
  • score — per-pillar relevance: exact match > prefix match > substring match. Use it as the flat-sort tiebreaker across pillars.
Render either the flat, pre-sorted results array or the grouped by_pillar map (keys are only the pillars that returned at least one match). counts reports the match tally for every pillar, including zero, which is what powers a “1 result in Contacts” summary line. partial names the pillars whose sub-query failed — e.g. a transient database error on one resolver — so the client can show a discreet “couldn’t search conversations” hint next to the pillars that did succeed. partial is empty on a fully successful fan-out. search_analytics_id is the row this query recorded for search analytics, or null when the write was de-duped. Save it and report the row the user picks with POST /api/v1/search-analytics/click — that click attribution is what makes the search-analytics click-through panel non-zero. See the Search Analytics API for the click endpoint and the reporting reads that back-fill those panels.