/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 an email attaches to it. Duplicates on an identifying kind are
merged by hand, never silently, and every merge is recorded.
Your auth stays yours
UserKit never authenticates your users. Your product does, and your server vouches for the one on the page.Federated identity
Your server signs the user’s id with an HMAC and
/v1/boot trusts the
claim — a wrong signature is refused, never downgraded.Proving an address
The magic link and the six-digit code are the only things that prove an
email, because they arrive in it.
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 athttps://api.userkit.dev — the quickstart goes from there to an
identified contact without you deploying anything.