Autenticação e chaves
O Magnum separa contas humanas, credenciais de backend e capacidades temporárias de checkout.
Chaves da API
Envie Authorization: Bearer mg_… nas rotas de integração. A chave pertence a uma organização, tem escopos, validade e revogação. Apenas um resumo criptográfico com segredo adicional é armazenado no banco. A chave completa aparece uma única vez na criação.
| Escopo | Acesso |
|---|---|
integrations:read / integrations:write | Consultar / criar integrações |
checkouts:read / checkouts:write | Consultar / criar sessões |
payments:read | Listar pagamentos |
metrics:read | Métricas e requisições |
webhooks:write | Configurar e consultar entregas |
Chamadas com uma chave secreta e um cabeçalho Origin são rejeitadas: use seu servidor, não o navegador. O bootstrap local cria uma chave de 30 dias; a API de contas permite escolher entre 1 e 365 dias.
Capacidades de checkout
O navegador usa Authorization: Checkout <token>. Esse token permite apenas operar a sessão correspondente, dentro do prazo e das restrições já gravadas. Não cria integrações nem lê outra organização.
Rotação e revogação
Crie a nova chave, atualize seu backend e revogue a anterior pela API de contas. Guarde segredos em variáveis privadas do Coolify. A revogação é consultada a cada chamada.
As credenciais da 4P Finance são diferentes das chaves Magnum e nunca são enviadas ao integrador ou ao navegador.
Entrar com Google
O OAuth do Google é opcional e usa a sessão existente do Better Auth. Configure GOOGLE_CLIENT_ID e GOOGLE_CLIENT_SECRET juntos na API e cadastre https://magnum.lat/api/auth/callback/google como URI de retorno autorizada. A opção aparece nas telas de login e cadastro. Enquanto as duas credenciais não estiverem configuradas, ela informa a indisponibilidade sem iniciar o OAuth; nenhum segredo é enviado ao navegador. Os escopos são identidade, perfil e e-mail. Novas contas continuam sujeitas a AUTH_ALLOW_SIGNUP, exigem e-mail verificado e os tokens são criptografados. URLs de retorno ficam restritas à origem do aplicativo.
Configuração de e-mail transacional
Para Resend, configure RESEND_API_KEY e RESEND_FROM na API e no worker; o domínio remetente deve estar verificado nessa conta Resend. Se RESEND_FROM estiver vazio, será usado MAIL_FROM. O SMTP legado usa SMTP_URL e MAIL_FROM. Mantenha credenciais fora do navegador e habilite AUTH_ALLOW_SIGNUP=true somente depois de validar uma entrega real autorizada.
Há templates nos dois idiomas para confirmação, recuperação de senha, boas-vindas após verificar e avisos de alteração de senha. Os links usam APP_URL exato, como https://magnum.lat. A verificação válida autentica a conta; tokens inválidos ou expirados não autenticam. Recuperação é de uso único e encerra sessões existentes.
Tentativas no Resend reutilizam a mesma chave de idempotência e o mesmo conteúdo. Os jobs não trocam de provedor automaticamente, e a mudança da credencial interrompe jobs existentes para revisão. accepted é diferente de entregue, lido ou verificado; webhooks de entrega/bounce não estão implementados. Um resultado SMTP que possa já ter sido aceito exige revisão do operador.