> ## Documentation Index > Fetch the complete documentation index at: https://docs.userkit.dev/llms.txt > Use this file to discover all available pages before exploring further. # Introdução > Contas para o seu time e contas para quem usa o seu produto — uma API, dois planos. 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. De uma conta nova até o seu primeiro contato identificado. Como o painel, a API e o seu produto se encaixam. Quatro famílias de token, quatro superfícies, nenhuma sobreposição. 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 comprovado se liga a ele. Duplicatas são unidas à mão, nunca em silêncio, e todo merge fica registrado. ## Duas formas de autenticar seus usuários Você escolhe por ambiente, então dá para avaliar um modo em test enquanto produção roda o outro. O UserKit é dono da conta: cadastro, login, verificação de e-mail e recuperação de senha, tudo sem revelar quem existe. Você já tem autenticação. Seu servidor atesta um usuário com um HMAC e o UserKit confia na afirmação. ## O que é preciso para começar Uma conta e uma chave. Cadastre-se em [app.userkit.dev](https://app.userkit.dev), gere uma chave no seu ambiente **test** e aponte o seu servidor para `https://api.userkit.dev` — os [primeiros passos](/pt-br/quickstart) levam daí até um contato identificado sem você subir nada.