API de WhatsApp para software houses que entregam projeto sob medida

O custo escondido de reinventar WhatsApp em cada projeto

O pedido chega em quase todo escopo: o sistema de agendamento precisa avisar o paciente, o ERP precisa mandar o boleto, o portal precisa notificar o corretor. Em muitas fábricas de software, cada time resolve do seu jeito. Um projeto usa uma biblioteca open source rodando num servidor do cliente, outro usa um fornecedor diferente, um terceiro tem um script que alguém escreveu e ninguém mais entende.

O preço aparece depois da entrega, no contrato de sustentação. Cada variante tem o próprio jeito de cair, a própria forma de reconectar e o próprio conhecimento concentrado numa pessoa. Quando essa pessoa sai, o projeto vira risco. E como a manutenção de WhatsApp raramente está precificada, a margem do contrato some em horas que ninguém fatura.

Padronizar numa API de WhatsApp gerenciada resolve a parte chata: a infraestrutura fica com o fornecedor, e o seu time só escreve a regra de negócio de cada cliente, que é o que o contrato paga.

Quem cuida do quê

Vale deixar claro no escopo, e para o próprio time, onde termina a responsabilidade da software house e onde começa a do fornecedor da API.

Essa divisão é a mesma discussão de hospedar ou contratar, tratada em detalhe em self-hosted vs gerenciada.

Um módulo de WhatsApp reaproveitável

O ganho real vem quando o WhatsApp vira um pacote interno da software house, com a mesma interface em todo projeto. Os pontos que costumam entrar nesse módulo:

• Configuração por projeto: API Key e nome da sessão vêm de variável de ambiente, nunca do código.
• Um serviço de envio que recebe telefone e conteúdo e esconde os detalhes da chamada.
• Um endpoint de webhook com o mesmo formato em todos os sistemas, que valida o sessionId recebido e enfileira o evento antes de processar.
• Tratamento de erro padronizado: a API devolve success, error e statusCode, o que permite um único mapeamento para log e alerta.
• Retentativa do seu lado. O SDK faz uma chamada HTTP simples e não repete sozinho. Decida no módulo quais erros merecem nova tentativa e com qual intervalo.

Em projeto Node, o núcleo desse módulo usa o SDK oficial:

import { DApi } from 'd-api-sdk'

const dapi = new DApi({ apiKey: process.env.DAPI_API_KEY! })
const SESSION = process.env.DAPI_SESSION_ID! // ex.: cliente-acme-producao

export async function provisionar(webhookUrl: string) {
  await dapi.sessions.create({ sessionId: SESSION, connectionMode: 'qr', webhookUrl })
  const { qrCodeImage } = await dapi.sessions.getQRCode(SESSION)
  return qrCodeImage // exiba na tela de configuração do sistema do cliente
}

export function avisar(telefone: string, texto: string) {
  return dapi.messages.sendText({ sessionId: SESSION, to: telefone, text: texto })
}

O detalhe de instalação e dos métodos disponíveis está no SDK Node.js e no guia de API de WhatsApp em Node.js. Projetos em outras stacks chamam a mesma REST; o guia de API de WhatsApp em Python mostra o padrão fora do Node.

Sessão por cliente, sessão por ambiente

Cada cliente da software house tem a própria sessão, o que isola número, credenciais e webhook. Dentro de um mesmo cliente, separe também os ambientes. Uma convenção simples evita o erro mais comum de todo projeto, que é mensagem de teste chegando em cliente de verdade:

• acme-dev: número de teste do time, webhook apontando para túnel local.
• acme-homolog: número de teste do cliente, usado na validação de aceite.
• acme-producao: número oficial do cliente, webhook do servidor de produção.

Se um dos projetos é um produto que o cliente vai vender para muitos usuários finais, com um número por usuário, o desenho muda de escala e se aproxima de um SaaS. Nesse caso, leia API de WhatsApp para SaaS.

Entrega, handover e contrato de manutenção

Projeto sob medida tem dia de entrega, e a parte de WhatsApp costuma ser a que mais gera chamado depois dele. Três cuidados reduzem esse volume:

1. Documente quem é dono da conta. Se o cliente vai assumir o sistema, a conta e a API Key devem estar no nome dele desde o início. Transferir depois é retrabalho.
2. Monitore o status da conexão. Assine o evento connection.status e mostre no painel do sistema se o número está connected, disconnected ou logged_out. O cliente resolve sozinho boa parte dos casos se enxergar o problema.
3. Precifique a sustentação pela conexão. A D-API cobra por conexão, não por mensagem, e o valor por conexão cai conforme o volume cresce. Com isso, o custo de WhatsApp de cada contrato é fixo e entra na proposta sem margem de segurança exagerada. As faixas estão em preços.

Para validar o módulo num projeto piloto, o trial é de 3 dias, sem cartão. Se a sua casa também atende agências ou opera automações para terceiros, a página de API de WhatsApp para agências mostra o modelo de operação de carteira.