Operations

Run the customer and operator workflows without crossing responsibilities.

Kendr has two operational surfaces that should stay distinct in both product design and documentation. Customers use the portal for registration, credits, API keys, and history. Operators use the admin plane for private execution configuration, pricing, announcements, and system oversight.

Login Admin dashboard Deployment and ops

Customer portal flow

The portal is the self-service surface for end users. It should focus on account state, wallet balance, packages, and API keys rather than exposing operator-only controls.

1
Register or sign in
Customers create an account or reuse an existing session through the hosted portal flow.
2
Buy credits
Configured packages top up the wallet so the customer can run hosted API calls.
3
Create API keys
Users mint keys, label them by environment, and revoke old ones when rotating credentials.
4
Inspect history
The dashboard exposes ledger entries, purchases, keys, and enabled surfaces for the account.

Admin control plane

The admin dashboard is the operator-facing system of record for how the hosted API behaves. It should be treated as a governance surface, not merely an analytics page.

Area What the admin controls
Leads and export Review legacy lead records and export CSV from the same backend that powers the site.
Packages Define customer credit packages and keep the wallet funding model aligned with surface pricing.
Execution configuration Manage private credentials, operational settings, and the active execution policy.
Surfaces Enable or disable surfaces and set credit costs for each surface.
Customers and usage Inspect accounts, purchases, usage volume, surface mix, and budget burn from the usage ledger.
Notifications Publish product announcements that installed clients can fetch through the app notifications endpoint.

Execution Governance

Private execution configuration is where operations, spend, and platform reliability meet. This is why implementation details belong in the admin plane instead of the public developer pages.

Operator-only configuration

Budget controls, private credentials, and execution policy should stay in authenticated admin workflows and should not be copied into public API docs or client examples.

  • Private credentials stay inside admin-managed configuration and should never leak into customer-facing docs or clients.
  • Surface pricing should be reviewed whenever operating costs or customer-facing surface scope changes.
  • Announcements and notifications should align with operational changes that users will actually feel.

Recommended operating rhythm

A clean operational loop keeps the product predictable. The checklist below is a practical baseline for teams running Kendr in a public install motion or a more active hosted environment.

  • Review credit package pricing whenever surface costs or expected margins move.
  • Check surface enablement before announcing new surfaces to customers.
  • Rotate private platform credentials and customer API keys on a schedule instead of waiting for incidents.
  • Watch the usage ledger for unexpected spend spikes, especially after opening new surfaces.
  • Use notifications for customer-visible changes instead of relying on ad hoc support messages.