Skip to main content
UserKit is two things that usually get built twice. The staff plane is the account system for your own team: users, organizations, roles carrying permissions, sessions, invitations, two-factor, API keys. It is what the panel talks to. The customer plane is the account system for your users — the people who sign up to the product you are building. UserKit calls them contacts, and they can be anonymous visitors or identified people, with the identity edges and merges that tie the two together. Both live behind one API, at /v1, told apart by which credential you present.

Quickstart

From a fresh account to your first identified contact.

Architecture

How the panel, the API and your own product fit together.

Credentials

Four token families, four surfaces, no overlap.

API reference

Every endpoint, with a playground.

​
The shape of it

Every organization is split into a live and a test environment, seeded when the organization is created. Test data and live data share a schema and never share rows. Which environment a machine request touches is decided by the key you present — uk_sk_live_… or uk_sk_test_… — and never by a parameter you send. Authorization is one query. A user belongs to an organization through a membership, the membership carries a role, and a role is a set of permissions. Resolving a session resolves identity, active organization, role and permissions together, which is why revoking a membership invalidates that session immediately. Your users are contacts. A contact starts as an anonymous visitor with an anonymous_id and first-touch attribution, and becomes identified when an external_id or a proven email attaches to it. Duplicates are merged by hand, never silently, and every merge is recorded.

​
Two ways to authenticate your users

You pick this per environment, so you can evaluate one mode in test while production runs the other.

Hosted

UserKit owns the account: sign-up, sign-in, email verification and password recovery, all non-enumerable.

Federated

You already have auth. Your server vouches for a user with an HMAC and UserKit trusts the claim.

​
What you need to start

An account and a key. Sign up at app.userkit.dev, mint a key in your test environment, and point your server at https://api.userkit.dev — the quickstart goes from there to an identified contact without you deploying anything.