API: login (POST) — public."user" / G_DB_POSTGRESS

Canónico no site: guias/login.md. Contrato: apis/02-auth.md · catálogo.

Autenticação por email + senha contra a BD G_DB_POSTGRESS (tabela principal public."user" e tabelas relacionais).

---

Endpoint

Item	Valor
Método	POST
URL	{BASE_URL}/api/v1/auth/login
Autenticação	Nenhuma (rota pública)

---

Corpo (Content-Type: application/json)

Campo	Obrigatório	Descrição
email	Sim	E-mail do utilizador (public."user".email).
password	Sim	Senha em texto plano (comparada com password via bcrypt).
tenantId	Não	UUID incluído no JWT para rotas multi-tenant.
tid	Não	Alias de tenantId.

Exemplo

{
  "email": "demo@centralcrm.local",
  "password": "suaSenhaSegura",
  "tenantId": "f1e2d3c4-b5a6-4789-8012-345678901234"
}

---

Resposta 200 OK

Campo	Tipo	Descrição
accessToken	string	JWT assinado com JWT_SECRET. Claims: sub (uuid do utilizador), opcional tenantId/tid, role/role_code, jti.
tokenType	"Bearer"
expiresIn	number	Segundos (JWT_EXPIRES_IN_SECONDS).
user	objeto	Perfil completo (UserFullResponseDto): dados de user + addresses, branding, documents, permissoes, personalData.

Efeitos na BD

• Atualiza public."user".metadata:
  • sessoesAtivas — incrementado em 1
  • ultimoAcesso — ISO 8601 do momento do login

Erros comuns

HTTP	Quando
401	Email inexistente ou senha incorreta → Credenciais inválidas.
403	Utilizador existe mas status ≠ ativo → Conta não disponível para login. Verifique o estado do utilizador.

---

Relação com outras rotas

• Rotas de companies podem exigir JWT com sub + tenantId. Envie tenantId no body do login ou use outro emissor de token.
• Após login, use Authorization: Bearer <accessToken> nas rotas protegidas (logout, GET/PATCH users, etc.).

---

Backend: LoginService + AuthUserEntity na conexão userProfilesConnection (BD G_DB_POSTGRESS).