Kendr.org

Kendr.org is a hosted product surface, not just a query endpoint.

The public site, hosted API, customer portal, SDKs, and auth flows are all part of one customer-facing product. This page explains how those pieces fit together so the docs stay organized around the hosted experience instead of drifting back into a marketing-only view.

API integration Features and surfaces Credits and billing

Product surfaces

Kendr exposes different surfaces depending on the user and the job. Keeping those boundaries clear is the main reason the docs section is organized as a wiki instead of another marketing page.

Surface Primary user What it does
index.html and marketing pages Prospects and evaluators Explains the product story, use cases, and early-access positioning.
docs/developer-api.html Developers before sign-in Shows the public hosted API contract, SDK references, schema download, and surface explorer.
/api/* and OAuth routes Apps, scripts, and backend services Handles account auth, OAuth, API key issuance, purchases, dashboard reads, and routed queries.
portal.html and user-dashboard.html Customers Handles registration, sign-in, wallet purchases, API key management, and customer-visible dashboard state.

Runtime lifecycle

Kendr’s public positioning is “research to execution.” The implementation underneath that positioning can be read as a four-stage lifecycle that stays consistent across the website, API, and dashboards.

1
Bring context
Users arrive through the site, portal, or app. Inputs can be questions, credentials, purchases, provider settings, or query requests.
2
Resolve identity and wallet
Kendr determines whether the caller is public, customer-authenticated, session-authenticated, or OAuth-authenticated, then checks wallet state and access.
3
Route the work
Surface selection, provider ordering, and pricing decide where the request runs and which upstream is used behind the scenes.
4
Persist the result
Kendr records ledger activity, keys, purchases, installs, feedback, and successful query charges so the product stays usable and auditable over time.

Account and wallet model

The hosted surface revolves around one customer account model. Users sign in, fund credits, create API keys, and run routed queries from the same underlying wallet.

Wallet

Packages add credits to the account balance. Successful hosted API calls deduct credits based on the selected surface.

Keys

API keys are minted per customer account and used for repeatable backend access without exposing upstream vendor credentials.

  • Customers never need to bring vendor credentials for the routed search surfaces.
  • The public Kendr contract stays stable even when routed provider configuration changes behind the scenes.
  • Credits are charged after successful provider completion, which keeps failed attempts from consuming wallet balance.

Documentation boundaries

Keep the docs section opinionated about scope. Kendr.org pages should explain the hosted product surface, API contract, auth, features, and billing. Desktop & CLI will cover installed-client flows later. That separation is what keeps the docs clean.

Rule of thumb

If a page tries to teach both how to call the hosted API and how to use a future desktop client workflow, it belongs in two different docs branches.