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 defines first-class surfaces grouped by workflow rather than by implementation detail so callers can keep one stable Kendr contract as the platform evolves.
| 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 internal execution details.
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.
Managed execution model
Kendr keeps private execution credentials and operational policy behind the platform boundary. The surface contract is public, while implementation choices can change without forcing client code to change.
Client integrations should depend on surface keys, request fields, credit costs, and result fields. Private execution policy and credential storage stay inside Kendr operations.
- Call GET /api/catalog when you need the current enabled surfaces and live price.
- Call POST /api/v1/query when you are ready to execute one of those surfaces.
- Use web_search for low-cost general search, ai_search for AI-ready retrieval, and web_answer for cited answer generation.
- Use credits_charged and remaining_credits to keep wallet state in sync after successful calls.