Contas e negócios
O Magnum usa Better Auth e PostgreSQL para identidade. Cada conta possui um negócio; o identificador interno Workspace continua nas rotas para delimitar os recursos, sem oferecer vários negócios por conta.
Identidade
Entrada, verificação de e-mail, recuperação e sessões usam /api/auth/*. Cadastro depende de transporte autorizado, entrega real validada e AUTH_ALLOW_SIGNUP habilitado. Nenhuma conta ou senha padrão é criada.
A verificação válida cria uma sessão autenticada. Um parâmetro de sucesso na URL não comprova verificação. Tokens de recuperação expiram, só podem ser usados uma vez e a redefinição válida revoga sessões anteriores.
Propriedade do negócio
O servidor limita cada conta a um negócio e associa integrações, chaves, sessões de checkout, pagamentos e configurações a ele. Informar o identificador de outro negócio não concede acesso. Os nomes plurais das rotas são mantidos por compatibilidade.
GET /v1/account/workspaces: vínculo da conta com seu negócio, quando configurado.POST /v1/account/workspaces: cria o negócio da conta; um segundo negócio é rejeitado.GET /v1/account/workspaces/:workspaceId/api-keys: consulta metadados de chaves.POSTna mesma rota: cria uma chave com escopos e papel autorizado.DELETE /v1/account/workspaces/:workspaceId/api-keys/:keyId: revoga uma chave própria.
Alterações por sessão exigem a origem exata do Magnum. Autorização é verificada em cada leitura e alteração. Convites, administração de papéis e troca entre vários negócios não fazem parte desta entrega.
Configuração de recebimento
O negócio cadastra seus endereços fixos de recebimento nas Configurações. GET e PUT /v1/console/workspaces/:workspaceId/settlement consultam e atualizam essa configuração autorizada. Cada destino possui rede e ativo compatíveis. O pagador não escolhe nem substitui o beneficiário no checkout.
A credencial 4P é administrada exclusivamente pelo operador do Magnum no backend. Os negócios não fornecem, consultam ou alteram essa chave global. Essa organização técnica não comprova autorização para processar vários negócios sob uma conta do fornecedor; o uso real ainda depende da aprovação expressa da 4P para o modelo aplicável.
API de configurações de recebimento
PUT /v1/console/workspaces/:workspaceId/settlement substitui a lista completa de destinos. O corpo é { "destinations": [{ "network": "ethereum", "address": "SEU_ENDERECO_MAINNET_VERIFICADO" }] }; substitua o endereço de exemplo por um endereço sob seu controle antes de enviar. Use destinations: [] apenas quando quiser limpar todos os destinos que não estiverem em uso.
Cada item aceita somente network e address. O servidor deriva o ativo do catálogo da rede, valida sintaxe de mainnet e checksums quando aplicáveis e permite um endereço por rede. A operação exige sessão de owner/admin verificado com até quinze minutos e origem exata da aplicação. Os endereços ficam criptografados e a alteração gera auditoria.
GET retorna os destinos do negócio autorizado com network, asset e address, além de availableNetworks, configuredNetworks, status e liveEnabled. Disponibilidade no catálogo técnico não comprova habilitação na operadora. Um endereço salvo não prova controle da carteira nem aprovação comercial; verifique ambos antes de qualquer operação real futura.
Uma rede repetida retorna DUPLICATE_NETWORK; endereço inválido retorna INVALID_SETTLEMENT_ADDRESS. Remover destino necessário a uma integração live ativa retorna SETTLEMENT_IN_USE. Criar ou editar integração live sem todos os destinos necessários retorna SETTLEMENT_REQUIRED; criar seu checkout real continua bloqueado depois disso.
GET /v1/console/workspaces/:workspaceId/provider retorna apenas metadados sanitizados da integração administrada pelo operador. Os antigos PUT e DELETE retornam 410 CENTRALIZED_PROVIDER_CONFIG e nunca salvam chaves da operadora enviadas pelo negócio.