Claude com Credenciais de API: Assinatura por Chat para Empresas e Integradores

A conta pessoal resolve o caso de quem assina meia dúzia de contratos por mês. Uma empresa tem outras perguntas: quem da equipe pode disparar um envio, como testar sem gastar cota real, como o que a Claude faz aparece no sistema que já existe, e onde fica a trilha para auditoria. É para isso que existe o segundo caminho de conexão: Claude com credenciais de API — as mesmas credenciais que a sua integração REST usa, com ambiente de homologação, as 24 ferramentas do servidor MCP e webhooks continuando a chegar no seu sistema.

Este guia é para o CTO, o gestor de operações ou o integrador que quer colocar a Claude no dia a dia de uma equipe sem abrir mão de governança. Se você é pessoa física, o caminho mais curto é conectar a Claude à sua conta; se você quer entender a camada MCP de forma geral, comece por Servidor MCP.

Dois modos, uma decisão simples

A regra de bolso: se o envio precisa aparecer em um sistema da empresa (CRM, ERP, pasta do cliente) ou ser feito por mais de uma pessoa, é credencial de API.

Antes de conectar: credencial e ambiente

Crie a credencial em app.signdocs.com.br → API. O processo, com o par Client ID e Client Secret e o fluxo OAuth2 por trás, está descrito em como obter credenciais. Duas decisões importam desde o primeiro dia:

• Comece em homologação. O endpoint hospedado de homologação é https://mcp-hml.signdocs.com.br/mcp; o de produção, https://mcp.signdocs.com.br/mcp. Em homologação nada tem efeito jurídico, a biometria é simulada e os dados expiram em 7 dias — ideal para a equipe aprender o que pedir e para você ver o que chega nos webhooks. Detalhes em ambiente de homologação.
• Uma credencial por equipe ou por ambiente. A cota, a trilha e os webhooks são por credencial. Dar à equipe comercial e ao financeiro credenciais separadas é o que permite saber depois quem enviou o quê e desligar um acesso sem afetar o outro.

O acesso à API em produção é um plano dimensionado com o time comercial; o sandbox é gratuito e não exige cartão.

Três formas de conectar com credencial

Claude Code: plugin oficial (endpoint hospedado)

Ao habilitar, o plugin pede Client ID, Client Secret e a URL do endpoint (o padrão é homologação; troque para produção quando for a hora). O segredo fica no chaveiro do sistema operacional, e nada roda localmente: o plugin fala com o endpoint hospedado.

Claude Desktop: extensão .mcpb (roda localmente)

Baixe a extensão nas Releases do plugin no GitHub, dê duplo-clique e informe as credenciais. Ela executa o servidor @signdocs-brasil/mcp-server na máquina do usuário via stdio. É a escolha de quem prefere que as credenciais não saiam do desktop.

Conector remoto com credencial (claude.ai e outros clientes)

O endpoint hospedado aceita as credenciais no cabeçalho de autorização — Authorization: Basic com clientId:clientSecret, ou um token Bearer obtido em /oauth2/token — e o ambiente por sessão em X-SignDocs-Environment: hml|production. É o mesmo mecanismo usado para passar o servidor no parâmetro mcp_servers da Messages API quando você constrói um agente próprio. Só a Claude é testada e suportada; outros clientes conectam pelo padrão aberto MCP.

Rodar você mesmo (stdio)

Mesmas ferramentas, mas o servidor roda na sua máquina (exige Node.js). Útil para redes restritas ou builds customizados.

As 24 ferramentas e o que cada grupo faz

"Sensível" significa que a ferramenta carrega a anotação de efeito destrutivo ou vinculante do protocolo MCP e um aviso na própria descrição. Clientes compatíveis, como a Claude, pedem confirmação humana antes de executá-la. Revise a configuração de aprovação automática do cliente que a sua equipe usa: a anotação é uma dica ao cliente, não um bloqueio no servidor.

Dois itens ainda não estão no catálogo: Sessões de Confiança e o reenvio do convite (resend-invite). Ambos existem na API REST e entram no servidor quando o SDK oficial os expuser.

Onde a confirmação humana acontece

Vale desenhar o fluxo de um envio feito por uma analista da equipe comercial, porque ele mostra onde cada controle mora:

1. A analista pede: "envia a proposta em anexo para o cliente X assinar com OTP". A Claude pede o link de upload — o arquivo vai direto ao SignDocs.
2. A Claude monta a chamada create_signing_session com nome, e-mail, CPF/CNPJ e o perfil de autenticação, mostra o resumo e espera a confirmação da analista. Esse é o primeiro controle: humano, no cliente.
3. O servidor MCP repassa a chamada à API com a credencial da equipe. Aqui valem a cota e os limites de requisições da credencial — segundo controle, no servidor.
4. A sessão é criada. O evento SIGNING_SESSION.CREATED sai pelo webhook registrado para aquela credencial e chega ao seu sistema como chegaria se a sessão tivesse sido criada por código — terceiro controle: o registro no sistema da empresa, independente do chat.
5. Quando o cliente assina, SIGNING_SESSION.COMPLETED chega ao mesmo webhook. O seu sistema baixa o documento e a evidência e arquiva. A analista pode perguntar à Claude "já assinou?", mas o sistema não depende disso.

O ponto central: a Claude é um canal de entrada, não o sistema de registro. Tudo o que ela cria passa pela mesma API, dispara os mesmos webhooks e gera as mesmas evidências. O que você já construiu para a integração REST — fila de webhooks, reconciliação, arquivamento — continua valendo sem nenhuma adaptação. Se ainda não construiu, comece por webhooks e eventos e webhooks em fila.

Governança: quem envia, quanto, e como provar

Quem pode enviar

Quem tem a credencial envia. Portanto, a credencial é o controle de acesso. Recomendações práticas:

• Uma credencial por equipe, com nome que diga a quem pertence. Rotacione o segredo quando alguém sai da equipe.
• Credenciais de homologação e de produção separadas, e o endpoint de produção configurado só para quem já demonstrou domínio do fluxo em homologação.
• Nos clientes que suportam aprovação automática de ferramentas, mantenha as ferramentas sensíveis fora da lista de aprovação automática.

Quanto pode ser gasto

A cota é por credencial e por documento. Um envelope com cinco signatários consome um documento. A Claude não tem como ultrapassar a cota: o servidor devolve o erro e a Claude o repete para a pessoa. Os limites de requisições e as respostas 429 estão em rate limits e idempotência; a lógica de custo em quanto custa a API.

Como provar depois

Cada assinatura concluída tem um pacote de evidências (.p7m) com quem assinou, quando, IP, geolocalização, dispositivo e método de autenticação, verificável de forma independente no verificador público. O fato de o envio ter nascido numa conversa com a Claude não muda o pacote: a evidência é da transação, não do canal. Veja o pacote de evidências e a verificação pública.

Casos em que a Claude com credencial rende mais

• Operação sem painel. Equipes que já vivem no Claude Code ou no Desktop resolvem o envio, o acompanhamento e a cobrança de pendentes sem abrir outra tela.
• Suporte interno. "Que status tem a transação do cliente Y?" ou "reenvia o código para a Ana" viram uma frase, com a Claude chamando list_transactions, get_transaction e resend_signing_session_otp.
• Depuração da integração. Pedir "testa o webhook cadastrado" dispara test_webhook, que envia um evento real assinado com HMAC ao seu endpoint — o jeito mais rápido de conferir a fila do outro lado.
• Agentes próprios. Com a Messages API e o parâmetro mcp_servers, um agente de compras pode preparar o envelope do contrato assim que a aprovação sai — com um humano confirmando o disparo. Fluxos fixos e de alto volume continuam melhores na API REST ou no nó do n8n.

Checklist de implantação

1. Credencial de homologação criada; plugin ou extensão instalado apontando para mcp-hml.
2. Webhook registrado (pelo painel, pela API ou pedindo à Claude) e recebendo SIGNING_SESSION.CREATED e COMPLETED no seu sistema.
3. Um envio completo em homologação, do link de upload à evidência baixada, feito por alguém da equipe sem ajuda técnica.
4. Política escrita: quem tem credencial, o que é aprovado automaticamente (nada sensível) e onde o documento assinado é arquivado.
5. Credencial de produção emitida no plano sob medida; endpoint trocado para mcp.signdocs.com.br apenas nos clientes autorizados.

Perguntas Frequentes