Skip to main content
Some operations aren’t about what a customer bought — they’re about administering your own tenant: correcting a usage counter, granting someone an exception, listing your users. Those need a different kind of trust than a logged-in customer has.
Kerne has no per-user permission system — no custom roles, no per-resource permissions, no admin flag on User. Administrative access is a property of the credential you authenticate with, not of the person behind it.
A regular user session (a JWT from login() / signup()) can only ever act on its own customer: its own profile, its own entitlements, its own usage. There is no way to elevate one — not by setting a field, not by any client-side call.

​
What requires your secret key

These accept only your secret key, called from your own backend, never from a browser:
  • Listing or managing other users (GET/PATCH /v1/users/:id for anyone but yourself)
  • Registering or looking up customers (kerne.customers.upsert / get / list / update)
  • Usage corrections (kerne.admin.setUsage / adjustUsage / resetUsage)
  • Entitlement overrides (kerne.admin.grant / revokeGrant)
  • Waitlist and invitation management

​
Building your own admin panel

If your team needs an internal tool on top of Kerne, that tool’s backend holds the secret key and calls these routes — after applying your own access control, deciding which of your teammates may reach that route at all. Kerne has no opinion on who counts as an admin inside your product. That’s yours to decide, and it stays in your application.

​
Next

Usage corrections

setUsage / adjustUsage / resetUsage reference.

Overrides

grant / revokeGrant — the one-customer exception.