Map customer workflows to the right Kendr surface.
Kendr.org exposes one routed API across multiple surface categories. The live catalog decides which surfaces are enabled and what they cost, but the public feature model stays stable: search, local, commerce, research, media, and travel all use the same contract.
Surface categories
The backend currently defines ten first-class surfaces. They are grouped by workflow rather than by upstream provider so callers can keep one stable Kendr contract even when provider routing changes.
| Category | Surfaces | Typical default cost |
|---|---|---|
| Search | Google Search, Google Images, Google News, Google Autocomplete | 1 to 2 credits |
| Local | Google Maps, Google Places | 2 credits |
| Commerce | Google Shopping | 2 credits |
| Research | Google Scholar | 2 credits |
| Media | Google Videos | 2 credits |
| Travel | Google Flights, Google Hotels | 5 credits |
Common workflows
The surface layer exists so product and integration docs can talk about workflows directly instead of forcing every caller to reason about provider-specific APIs.
Use Search, News, Images, and Videos for broad discovery, monitoring, or content collection flows.
Use Maps and Places for location-aware business research, service discovery, and geographic lookups.
Use Shopping when you need merchant listings, price signals, or product comparisons.
Use Scholar for papers, citations, and publication-oriented workflows.
Use Flights and Hotels when the workflow is trip planning, pricing, or itinerary research.
Autocomplete is useful for suggestion, query expansion, and assisted search experiences.
Shared request shape
Every feature runs through the same request model. Send the surface name, the primary query, and any optional parameters inside params or flattened at the top level.
Core fields
- surface selects the Kendr capability, such as google_search or google_flights.
- query is always required and remains the primary caller input.
- params carries optional fields like gl, hl, page, location, or travel dates.
Catalog-driven fields
- credits_cost is exposed through the live catalog and dashboard payload.
- required_params and parameter_help come from the surface definition itself.
- sample_request is published in the catalog so client tooling can bootstrap examples directly.
Provider routing model
Kendr keeps provider credentials and provider ordering behind the platform boundary. The surface contract is public, while the selected upstream can vary per configured surface without forcing client code to change.
Configured surfaces can route across SearchAPI, Serper, SerpApi, and Google Programmable Search depending on the live catalog state.
- Call GET /api/catalog when you need the current enabled surfaces, configured provider, or live price.
- Call POST /api/v1/query when you are ready to execute one of those surfaces.
- Read provider_attempts in the response when you need to debug fallback behavior.