Skip to main content
O UserKit é duas coisas que normalmente acabam sendo construídas duas vezes. O plano de staff é o sistema de contas do seu próprio time: usuários, organizações, papéis carregando permissões, sessões, convites, dois fatores, chaves de API. É com ele que o painel conversa. O plano de clientes é o sistema de contas dos seus usuários — as pessoas que se cadastram no produto que você está construindo. O UserKit chama essas pessoas de contatos, e elas podem ser visitantes anônimos ou pessoas identificadas, com as arestas de identidade e os merges que ligam as duas pontas. Os dois vivem atrás de uma única API, em /v1, distinguidos pela credencial que você apresenta.

Primeiros passos

De uma conta nova até o seu primeiro contato identificado.

Arquitetura

Como o painel, a API e o seu produto se encaixam.

Credenciais

Quatro famílias de token, quatro superfícies, nenhuma sobreposição.

Referência da API

Todos os endpoints, com playground.

​
O formato da coisa

Toda organização é dividida em um ambiente live e um test, criados junto com ela. Dados de teste e dados de produção compartilham o schema e nunca compartilham linhas. Qual ambiente uma requisição de máquina toca é decidido pela chave que você apresenta — uk_sk_live_… ou uk_sk_test_… — e nunca por um parâmetro que você envia. Autorização é uma consulta. Um usuário pertence a uma organização por meio de um vínculo (membership), o vínculo carrega um papel, e um papel é um conjunto de permissões. Resolver uma sessão resolve identidade, organização ativa, papel e permissões de uma vez — por isso revogar um vínculo invalida aquela sessão na hora. Seus usuários são contatos. Um contato começa como visitante anônimo, com um anonymous_id e atribuição de primeiro toque, e se torna identificado quando um external_id ou um e-mail se liga a ele. Duplicatas num tipo identificante são unidas à mão, nunca em silêncio, e todo merge fica registrado.

​
Sua autenticação continua sua

O UserKit nunca autentica os seus usuários. O seu produto faz isso, e o seu servidor atesta quem está na página.

Identidade federada

Seu servidor assina o id do usuário com um HMAC e o /v1/boot confia na afirmação — uma assinatura errada é recusada, nunca rebaixada.

Comprovar um endereço

O magic link e o código de seis dígitos são as únicas coisas que comprovam um e-mail, porque chegam nele.

​
O que é preciso para começar

Uma conta e uma chave. Cadastre-se em app.userkit.dev, gere uma chave no seu ambiente test e aponte o seu servidor para https://api.userkit.dev — os primeiros passos levam daí até um contato identificado sem você subir nada.