Portal de Inteligência Artificial da AppsToB
Para continuar, faça login com sua conta Google corporativa. O acesso é restrito ao domínio autorizado.
Portal de Inteligência Artificial da AppsToB
Histórico de Requisições
Carregando...
| Data/Hora | Modelo | Complexidade | Cache | Tokens (↑↓) | Total (s) | Status |
|---|
Preços de Tokens
Carregando...
| Modelo (ID) | Input $/1k tok | Output $/1k tok | Vigência | Descrição |
|---|
Custo Acumulado por Usuário
Carregando...
| Usuário | Requisições | Tokens Total | Se Gemini Flash (BRL) | Se Claude Haiku (BRL) |
|---|
Integrações
Carregando...
| Evento | Origem | E-mail (de → para) | WhatsApp (de → para) | Mensagem | Criado por |
|---|
Nenhuma regra cadastrada.
- Acesse myaccount.google.com com a conta de envio
- Vá em Segurança → Verificação em duas etapas
- Role até o final → clique em Senhas de app
- Crie uma nova senha → "Outro (nome personalizado)" → ex.: apps-proxy SMTP
- O Google exibe um código de 16 letras (ex.:
abcd efgh ijkl mnop) - Cole no campo App Password acima e clique em Salvar
Espaços são removidos automaticamente.
Notificações WhatsApp são entregues via n8n + Evolution API. URL e secret configurados via Coolify (env vars).
O n8n recebe { to, channel: "whatsapp", message } e encaminha para a Evolution API. Para alterar URL ou secret, edite as env vars N8N_WEBHOOK_URL / N8N_WEBHOOK_SECRET no Coolify.
Escaneie com o WhatsApp do celular remetente. Expira em 60s.
Mensagens entregues via Meta Cloud API (WABA). Credenciais configuradas via Coolify (env vars META_WABA_*).
Para alterar credenciais, edite META_WABA_ENABLED, META_WABA_PHONE_NUMBER_ID, META_WABA_ACCESS_TOKEN e META_WABA_API_VERSION no Coolify e faça redeploy.
Nenhuma mensagem recebida ainda.
| Recebido em | De | Mensagem |
|---|
Nenhum status recebido ainda.
| Atualizado em | Para | Status | Detalhe |
|---|
| Prefixo | Escopos | Portal | Label | Criada em | Status |
|---|
Nenhuma chave para este vínculo.
| Categoria | Chave | Atualizado em | Atualizado por |
|---|
Nenhum segredo cadastrado no banco ainda — chaves ainda não migradas continuam servidas via env var do Coolify.
Autenticação
Toda chamada M2M usa uma API Key no header x-api-key. Cada chave é
vinculada a um par cliente × plataforma e a uma lista de
escopos (features habilitadas) — a mesma chave nunca pode agir
em nome de outro cliente, e só acessa a feature contracts se esse
escopo tiver sido concedido a ela.
O par existe porque o mesmo cliente pode contratar mais de uma integração (por exemplo um ERP e o E-Store ao mesmo tempo), cada uma com sua própria chave.
Para solicitar uma chave, peça a um admin AppsToB para gerá-la em
Integrações → Clientes × Plataformas — o valor é mostrado
uma única vez no momento da criação (não é recuperável depois). Junto da chave
você recebe o seu clienteCodigo e o plataformaId, que
devem ser enviados no body abaixo.
Enviar contrato para assinatura
POST /v1/contracts/send
Gera o documento a partir de um template cadastrado no painel admin, substitui as
variáveis e envia para assinatura eletrônica via D4Sign. O contrato é criado de
forma assíncrona — a resposta traz um contractLogId
para acompanhamento.
Requisição em multipart/form-data (não JSON), para suportar anexos
binários. Os campos signatories, variables e
observers vão como texto contendo JSON serializado.
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
templateId | string (uuid) | Sim | ID do template cadastrado no painel admin |
clienteCodigo | string | Sim | Seu código de cliente na AppsToB (ex.: CLI-001), fornecido junto com a API key — não é escolhido livremente pelo integrador. Junto de plataformaId, precisa corresponder ao par vinculado à sua chave; divergente disso, rejeita com 403 |
plataformaId | integer | Sim | Id da plataforma contratada (ex.: 1), fornecido junto com a API key |
signatories | JSON (string) | Sim | Array de signatários — name, email, role (opcional, default "1" — é o próprio código act da D4Sign, ver tabela abaixo) |
variables | JSON (string) | Sim | Mapa key/value com os placeholders do template |
attachments | arquivos binários | Não | 0 a 5 arquivos, até 50MB cada, anexados ao envelope de assinatura |
observers | JSON (string) | Não | Pessoas que acompanham o documento sem poder assinar |
Papéis de signatário (signatories[].role):
Desde a sessão 87, role é o próprio código
act da D4Sign (como string, ex.: "role":"4")
— não um nome semântico nosso. A D4Sign suporta 13 códigos nativamente;
o AppsToB hoje habilita 7 — enviar um código não habilitado
(mesmo que exista na D4Sign) resulta em 400. Linhas verdes =
habilitado.
role | Papel (act D4Sign) | Quando usar (negócio) | Habilitado? |
|---|---|---|---|
"1" | Assinar | Padrão — é o único que usamos hoje | ✅ |
"2" | Aprovar | Alguém precisa validar o conteúdo antes de seguir, sem "assinar" juridicamente (ex.: gerente aprova valor) | não |
"3" | Reconhecer | Confirma que teve conhecimento do documento, sem se comprometer com ele | não |
"4" | Assinar como parte | Uma das partes contratantes formais (ex.: comprador/vendedor identificado no contrato) | ✅ |
"5" | Assinar como testemunha | Testemunha do ato, sem ser parte do negócio | ✅ |
"6" | Assinar como interveniente | Terceiro que intervém no contrato sem ser parte principal (ex.: cônjuge autorizando) | não |
"7" | Acusar recebimento | Só confirma que recebeu o documento — nem assina nem aprova | não |
"8" | Emissor, Endossante e Avalista | Títulos de crédito (nota promissória, duplicata) | não |
"9" | Emissor, Endossante, Avalista, Fiador | Idem #8 + responsabilidade de fiador | não |
"10" | Fiador | Garante a dívida caso o devedor principal não pague | ✅ |
"11" | Parte e fiador | É parte do contrato e garante como fiador ao mesmo tempo | ✅ |
"12" | Responsável solidário | Responde junto com o devedor principal, sem ser "parte" do contrato | ✅ |
"13" | Parte e responsável solidário | É parte do contrato e responde solidariamente | ✅ |
Precisa de um código ainda não habilitado ("2", "3", "6", "7", "8" ou "9")?
Fale com a AppsToB — é decisão de negócio habilitar novos códigos, não uma
limitação técnica da D4Sign. Lista completa e fonte oficial:
docs/reference/D4SIGN_API.md.
Exemplo — variables:
{"RAZAO_SOCIAL":"Empresa LTDA","CNPJ_CPF":"12.345.678/0001-99"}
As chaves de variables devem corresponder exatamente aos placeholders
do template (fieldsUsed, consultável via
GET /api/admin/contracts/templates/:id no painel admin) — nenhuma pode
faltar, nenhuma extra é aceita.
Exemplos de payload — signatories
Copie e adapte. Todo signatories/observers vai como
texto contendo JSON serializado (JSON.stringify(...)) — não
é um array de objetos direto no multipart.
1. Um único signatário — caso mais simples, role omitido usa o padrão ("1" = assinar).
[
{ "name": "João Silva", "email": "joao@empresa.com.br" }
]
2. Múltiplos signatários, papéis diferentes — sem observadores.
[
{ "name": "João Silva", "email": "joao@empresa.com.br", "role": "1" },
{ "name": "Maria Fiadora", "email": "maria@empresa.com.br", "role": "10" },
{ "name": "Pedro Testemunha","email": "pedro@empresa.com.br", "role": "5" }
]
3. Múltiplos signatários + observers — alguém acompanha sem poder assinar.
// signatories
[
{ "name": "João Silva", "email": "joao@empresa.com.br", "role": "1" },
{ "name": "Maria Fiadora", "email": "maria@empresa.com.br", "role": "10" }
]
// observers (campo separado, mesmo padrão de string JSON serializada)
[
{ "email": "gerente@empresa.com.br", "permission": 1 }
]
4. Papéis combinados — alguém que é parte do contrato e fiador/responsável solidário ao mesmo tempo (não precisa de duas entradas).
[
{ "name": "João Silva", "email": "joao@empresa.com.br", "role": "1" },
{ "name": "Carla Sócia", "email": "carla@empresa.com.br", "role": "11" }
]
Requisição completa (multipart)
Junta tudo — header, campos de texto e anexo — como o request realmente sai na rede.
Sem observers:
curl -X POST https://ia.appstob.com.br/v1/contracts/send \
-H "x-api-key: SUA_CHAVE_AQUI" \
-F "templateId=550e8400-e29b-41d4-a716-446655440000" \
-F "clienteCodigo=CLI-001" \
-F "plataformaId=1" \
-F 'signatories=[{"name":"João Silva","email":"joao@empresa.com.br","role":"1"},{"name":"Maria Fiadora","email":"maria@empresa.com.br","role":"10"}]' \
-F 'variables={"RAZAO_SOCIAL":"Empresa LTDA","CNPJ_CPF":"12.345.678/0001-99"}' \
-F "attachments=@pedido_de_compra.pdf"
Mesmo exemplo, agora com observers (linha extra, resto idêntico):
curl -X POST https://ia.appstob.com.br/v1/contracts/send \
-H "x-api-key: SUA_CHAVE_AQUI" \
-F "templateId=550e8400-e29b-41d4-a716-446655440000" \
-F "clienteCodigo=CLI-001" \
-F "plataformaId=1" \
-F 'signatories=[{"name":"João Silva","email":"joao@empresa.com.br","role":"1"},{"name":"Maria Fiadora","email":"maria@empresa.com.br","role":"10"}]' \
-F 'variables={"RAZAO_SOCIAL":"Empresa LTDA","CNPJ_CPF":"12.345.678/0001-99"}' \
-F 'observers=[{"email":"gerente@empresa.com.br","permission":1}]' \
-F "attachments=@pedido_de_compra.pdf"
N anexos: repita -F "attachments=@..." uma vez por
arquivo — mesmo nome de campo, um -F por parte. Limite de
5 anexos por envio, 50MB por arquivo — passar de qualquer um dos
dois retorna 400 com mensagem explicando qual limite foi excedido.
Anexo maior que 50MB? Compacte do seu lado antes de enviar (o limite é o teto real de upload da própria D4Sign — não é uma restrição arbitrária nossa). Não fazemos compactação automática hoje.
curl -X POST https://ia.appstob.com.br/v1/contracts/send \
-H "x-api-key: SUA_CHAVE_AQUI" \
-F "templateId=550e8400-e29b-41d4-a716-446655440000" \
-F "clienteCodigo=CLI-001" \
-F "plataformaId=1" \
-F 'signatories=[{"name":"João Silva","email":"joao@empresa.com.br","role":"1"}]' \
-F 'variables={"RAZAO_SOCIAL":"Empresa LTDA","CNPJ_CPF":"12.345.678/0001-99"}' \
-F "attachments=@pedido_de_compra.pdf" \
-F "attachments=@nota_fiscal.pdf" \
-F "attachments=@comprovante_endereco.jpg"
Respostas
202 — aceito, envio em andamento
HTTP/1.1 202 Accepted
{
"contractLogId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
"status": "pending"
}
400 — payload inválido / variables não corresponde ao template
HTTP/1.1 400 Bad Request
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Template \"Contrato de Compra\" — variables inválidas (faltando: CNPJ_CPF (CNPJ / CPF)).",
"detail": {
"templateName": "Contrato de Compra",
"missingFields": [{ "key": "CNPJ_CPF", "label": "CNPJ / CPF" }],
"unknownFields": [],
"forbiddenFields": []
}
}
}
401 — API key ausente, inválida ou revogada
HTTP/1.1 401 Unauthorized
{
"error": { "message": "API key inválida ou ausente.", "type": "unauthorized" }
}
Não distinguimos "não existe" de "foi revogada" — se fizéssemos, a rota viraria uma forma de descobrir quais chaves são válidas.
403 — seu acesso está suspenso (a chave está correta)
HTTP/1.1 403 Forbidden
{
"error": {
"message": "Cliente inativado — todos os acessos de integração estão suspensos. Fale com o time AppsToB.",
"type": "cliente_inativo"
}
}
O campo type diz o que aconteceu: cliente_inativo (seu
cadastro foi inativado — todas as suas integrações param),
vinculo_inativo (só esta integração foi desativada, as outras seguem)
ou forbidden_scope (sua chave não recebeu o escopo
contracts). Nos três casos não troque de chave: a
credencial está válida, o que mudou foi a liberação de acesso. Fale com o time
AppsToB.
403 — o par clienteCodigo/plataformaId do body não é o da sua API key
HTTP/1.1 403 Forbidden
{
"error": {
"code": "TENANT_MISMATCH",
"message": "Esta API key não está vinculada ao cliente \"CLI-001\" (plataforma 1)."
}
}
Este mesmo 403 aparece tanto quando o par pertence a outra chave quanto quando ele
não existe no cadastro — é deliberado, para a rota não servir de consulta sobre
quais clientes existem. O código continua TENANT_MISMATCH por
compatibilidade com integrações já publicadas.
422 — erro na geração/envio (template inativo, falha na D4Sign)
HTTP/1.1 422 Unprocessable Entity
{
"error": { "code": "CONTRACT_ERROR", "message": "Template não encontrado ou inativo" }
}
Webhook de confirmação de assinatura
POST /v1/contracts/webhook
Endpoint que a D4Sign chama para notificar eventos (signed,
cancelled). Não requer API Key — a autenticação é via HMAC SHA-256 no
header Content-Hmac, calculado como
SHA256(uuid_document + secret).
Este endpoint sempre retorna 200 para eventos conhecidos, mesmo em
caso de erro interno, para evitar retentativas desnecessárias da D4Sign. Retorna
401 apenas quando o HMAC é inválido.
Spec OpenAPI completa (todos os campos, exemplos e schemas):
docs/openapi-public.yaml.
⚙️ Configurações
| Nível | Descrição | Modelo primário | Fallback | Rescue | Usar model-client |
|---|---|---|---|---|---|
| L1 | Simples | ||||
| L2 | Análise textual | ||||
| L3 | Técnico | ||||
| L4 | Especialista |
Central de Ingestão BI
Nova conexão
SQL Server
Vem da aba aberta. Para cadastrar no outro motor, troque de aba.CRM — Meu dia
Meu dia
CRM — Funil de vendas
—
Busca
Nova negociação
—
AbertaCriar tarefa
Criar contato
CRM — LinkedIn assistido
Prospecção assistida
Nova prospecção
Cria o contato na fila — nasce no estágio "Identificado".
👥 Manutenção de Usuários
Quem acessa o painel administrativo da AppsToB.
Carregando...
| Usuário | Perfil | Status | Convidado em |
|---|
Nenhum usuário cadastrado.
Convidar usuário
Manda um e-mail de convite. A pessoa só entra depois de aceitar e logar com o Google no mesmo endereço.
Editar usuário
🎧 Help-Desk
Vincular Requisito
Vincular tarefa
Mesclar Chamados
O chamado escolhido abaixo será fechado com situação "mesclado" e suas mensagens passarão a aparecer nesta timeline.
Vincular Ticket Relacionado
Cadastrar um emissor significa aceitar como verdade a identidade de qualquer usuário que aquele sistema assinar, dentro do vínculo escolhido. O apps-proxy só guarda a URL do JWKS público — nunca material capaz de emitir o token.
| Emissor (iss) | Empresa origem | Vínculo | Alg. | Solicitantes | Situação | Ações |
|---|
Nenhum emissor cadastrado — a integração via SDK está inativa.
👤 Cadastro de Clientes
Carregando...
| Código | Razão Social | Fantasia | CNPJ/CPF | Natureza | Ativo |
|---|
Nenhum cliente cadastrado ainda.
Salve o cadastro primeiro para poder adicionar formas de contato.
| Forma de contato | Contato | Setor | DDD | Número/Endereço | Favorito |
|---|
Salve o cadastro primeiro para ver as conversas registradas.
Rascunho da próxima mensagem
A IA sugere um texto — você decide o que enviar. Nada é enviado automaticamente pelo sistema.
Nenhuma conversa registrada
Mensagens de WhatsApp e e-mail aparecem aqui automaticamente, assim que a pessoa falar com a AppsToB ou receber uma mensagem.
⚙️ Configurações do funil
Nenhum funil cadastrado ainda
Crie o primeiro funil para começar a desenhar o quadro.
Os três precisam crescer nessa ordem — atenção ≤ escapando ≤ frio. Se "frio" ficar menor que "atenção", a etiqueta amarela do cartão para de aparecer.
Etapas do quadro
| Ordem | Etapa | Situação | Ações |
|---|
Motivos de perda
Catálogo global — vale para todos os funis. Aparecem no formulário de "Marcar como perdida". Desativar tira o motivo do formulário, mas as perdas já registradas com ele continuam contando no relatório de objeções — por isso não existe excluir.
Novo funil
Cortes de tempo (dias sem toque)
| ID | Descrição | Tipo |
|---|