Skip to main content
Contatos entram no seu produto de duas formas. Você escolhe por ambiente, então dá para avaliar uma em test enquanto produção roda a outra.

Hosted

O UserKit é dono da conta. Cadastro, login, verificação de e-mail e recuperação de senha são endpoints que você chama. Os formulários são seus; as regras são nossas.

Federado

Você já tem autenticação. Seu servidor atesta um usuário com um HMAC sobre o id dele, e o UserKit confia na afirmação.

​
Qual dos dois

Se você está começando do zero, hosted. Se o seu produto já tem uma tabela de usuários, federado — assim você não migra ninguém.

​
Definindo

Exige organization:update. Os dois ambientes começam como hosted.

​
Lendo isso de uma tela de login

Uma tela de login precisa saber em que modo está antes de conseguir se renderizar, e receber isso como configuração significa que mudar o modo não faz nada até alguém fazer deploy. Pergunte:
200
Público e cacheável — nenhuma chave além da publicável, nenhuma checagem de Origin, então funciona a partir de um servidor renderizando a página. providers lista com o que um contato de fato conseguiria entrar, então ligar o Google no painel acende o botão sozinho. Veja Login social.

​
Os modos recusam um ao outro

Os endpoints do modo em que o ambiente não está respondem 409 em vez de virarem em silêncio um segundo caminho de login:
/v1/contact-auth/* em ambiente federado
/v1/boot com external_id, em ambiente hosted
Dois logins num sistema de contas é como o mais fraco vira a porta de entrada.
Boot anônimo — uma chave publicável e um anonymous_id, sem external_id — funciona nos dois modos. Rastreamento de visitante e atribuição não são uma questão de autenticação, então nunca batem na verificação de modo.

​
O que os dois modos têm em comum

Qualquer que seja a escolha, as mesmas coisas valem. Contatos são contatos. As mesmas linhas, as mesmas arestas de identidade, a mesma atribuição, os mesmos merges. O modo decide como um contato é comprovado, não o que um contato é. Só um link comprova um e-mail. Nos dois modos, email_verified vira verdadeiro quando uma mensagem que chegou na caixa de entrada é clicada — nunca porque um e-mail foi passado para uma API. Sessões carregam verified. Uma identidade comprovada emite uma sessão de contato verificada; uma não comprovada emite uma sessão marcada como não verificada e barrada de qualquer coisa por onde os dados de outra pessoa pudessem vazar. As respostas não enumeram. Cadastro, magic link, reenvio e esqueci-a-senha todos respondem 202 incondicionalmente, e o login responde um 401 uniforme, nos dois modos. A lista de origens é o portão. Todo endpoint de chave publicável que escreve alguma coisa — boot, cadastro, login, magic link, social — confere a lista de origens permitidas antes de qualquer outra coisa. As duas leituras públicas endereçadas por chave, /v1/config e /v1/jwks, não conferem: elas não cunham nada e não mandam e-mail para ninguém, e barrá-las só impediria um servidor de renderizar sua tela de login — porque servidor nenhum manda Origin. Seu backend verifica do mesmo jeito. Qualquer que seja o modo do ambiente, uma sessão de contato compra um JWT de vida curta que a sua API confere offline. Veja Tokens de sessão.