customer, ops, driver, bko).
Cadastro de passageiro (sign-up)
Cadastro autônomo de passageiro, disponível apenas no projetocustomer. Ao concluir, o passageiro tem conta ativa, perfil de Customer com document e endereço, identidade de billing vinculada e já recebe um par de tokens.
Login por username + senha (sign-in)
Login tradicional. Ousername aceita email ou telefone. Disponível em todos os projetos.
Nos projetos
ops, driver e bko, o login exige a permissão de acesso correspondente (access:ops, access:driver, access:bko), derivada dos vínculos ativos do usuário. O projeto customer não exige permissão de acesso.Login social (Google OAuth)
Login via provedor social. O cliente obtém um token do provedor e o envia à API. Comportamento:- O usuário é localizado por
googleProviderId; se não houver, tenta poremaile, ao encontrar, vincula ogoogleProviderIde marca o email como verificado. - Se nenhum usuário existir, a requisição é rejeitada com
401— o login social não cria contas automaticamente. - No projeto
customer, o login social garante que exista umCustomerpara o usuário. Nos projetos de staff, valida a permissão de acesso (access:{api}).
Conta criada em venda POS
Quando uma venda presencial precisa criar uma conta para o passageiro, o sistema resolve ou criaUser e Customer antes do pedido. O documento do Customer é obrigatório nesse fluxo.
Esse fluxo não cria Invite de ativação. O acesso autônomo do passageiro deve acontecer por cadastro/login customer ou recuperação de senha, conforme o estado da conta.
Recuperação de senha
A recuperação de senha usa OTP: o cliente solicita um código, recebe umotpId, e o fluxo de reset valida otpId + code antes de definir a nova senha.