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, download paths, and install 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 hosted 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, account credentials, purchases, 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, account access, and pricing decide whether the request can run and how credits are applied.
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 hosted 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 private platform credentials.

  • Customers never need to bring third-party credentials for Kendr-hosted surfaces.
  • The public Kendr contract stays stable as internal implementation choices evolve.
  • Credits are charged after successful request 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 covers installed-client flows and local runtime behavior. 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.