Painel do estabelecimento
Entre com uma conta verificada em /pt/dashboard ou /en/dashboard. Cada negócio é um workspace independente. A seleção do negócio altera o escopo, sem conceder permissões adicionais.
Primeira integração
- Crie seu negócio após entrar.
- Em Checkouts, crie uma configuração com nome.
- Informe origens HTTPS exatas e as redes para testar. As escolhas de sandbox não confirmam habilitação no provedor.
- Escolha idioma, tema claro/escuro/sistema, destaque e arredondamento.
- Abra a prévia. Ela usa uma configuração isolada com validade de dez minutos e não amplia os domínios do checkout original.
- Crie uma chave com permissões necessárias e guarde o segredo no backend. Ele aparece somente uma vez.
- Gere sessões por pedido no backend, com valor BRL fixo e origem autorizada. Envie somente a URL retornada ao navegador.
O código de incorporação copiado no painel contém uma sessão temporária de exemplo. Para cobranças contínuas, gere novas sessões pela API.
Telas e dados
Visão geral com BRL recebido e USDT liquidado separados; transações paginadas e histórico; cobranças com validade; chaves com rotação e revogação; requisições sanitizadas; webhooks assinados, testes identificados e reenvio controlado; configurações de perfil, negócio, senha, sessões e credencial 4P criptografada.
A exportação CSV exige autorização, limita 5.000 registros e neutraliza fórmulas. O papel viewer não altera configurações. Operações sensíveis exigem uma sessão criada nos últimos quinze minutos.
Produção e conta
Pagamentos reais continuam desativados. Salvar a credencial 4P deixa o estado pending_activation e não supera a política. Seleção de carteira e destinatários terceiros permanecem indisponíveis.
Não há saldo custodiado. Recebimento de Pix não significa liquidação cripto. Totais de liquidação dependem de confirmação de destino, rede, quantidade e hash. Telas vazias representam ausência de registros.
Confirmação, recuperação, boas-vindas e avisos de alteração de senha possuem templates PT/EN e ficam criptografados em EmailOutbox. O worker envia pelo Resend ou SMTP. Tokens de recuperação expiram, não podem ser reutilizados e a redefinição encerra sessões anteriores. A verificação válida cria uma sessão autenticada e agenda uma única mensagem de boas-vindas. Cadastro exige transporte e remetente autorizados, além de AUTH_ALLOW_SIGNUP habilitado. O status accepted indica apenas aceite pelo provedor, não entrega à caixa de entrada. A opção Google permanece visível, mas informa indisponibilidade enquanto faltarem as credenciais OAuth.
API de sessão
GET /v1/console/session retorna usuário e negócios autorizados. GET /v1/console/sessions lista sessões próprias, e DELETE /v1/console/sessions/:id revoga uma sessão.
Sob /v1/console/workspaces/:workspaceId:
| Recurso | Métodos e finalidade |
|---|---|
/settings | GET e PATCH, dados do negócio |
/overview | GET, período days=7..90 e ambiente |
/transactions | GET, paginação, busca, status e datas |
/transactions/export | GET, CSV autorizado |
/transactions/:id | GET, detalhes e eventos |
/requests | GET, histórico sanitizado |
/integrations | GET e POST, configurações |
/integrations/:id | PATCH, aparência e permissões |
/integrations/:id/preview | POST, prévia isolada |
/checkouts | GET e POST; criação exige Idempotency-Key |
/checkouts/:id/link | GET, acesso auditado ao link válido |
/api-keys/:id/rotate | POST, rotação atômica |
/webhooks | GET e POST, endpoints |
/webhooks/:id | DELETE, desativação |
/webhooks/:id/test | POST, teste identificado |
/deliveries | GET, histórico de entregas |
/deliveries/:id/retry | POST, reenvio controlado |
/provider | GET, PUT e DELETE, credencial e estado |
Todos exigem cookie de conta verificada. Alterações exigem origem exata e papel owner/admin. Os enums e identificadores da API são estáveis nos dois idiomas.
O formulário público usa POST /v1/public/support com email, subject, message, locale e campo opcional website vazio. A mensagem é armazenada criptografada. A referência confirma recebimento no sistema, não entrega por e-mail.
Os períodos da visão geral usam dias de calendário UTC. Recebimentos e liquidações seguem a data de confirmação, incluindo cobranças criadas antes do período. Pendências incluem cobranças válidas antes e depois da criação do QR.