A janela de 24h grátis acaba em 1º/out/2026. Veja o que muda e como reduzir custo. Entrar na comunidade

Integre sua operação em minutos

O jeito mais simples: um try/catch que reporta quando sua operação WhatsApp dá erro — um POST minúsculo, só quando algo quebra. Opcionalmente, você também manda heartbeats de "tô no ar". Em troca, você ganha alertas de outage do grupo, comparativo anônimo e um selo de status — tudo alimentado pelos sinais reais de quem constrói em cima da Meta.

Integre com IA Claude · Cursor

Tem um agente de código? Cole o prompt, preencha suas credenciais (pegue aqui) e ele implementa o reporte de falhas no seu projeto — try/catch → /fail, com webhook assinado opcional. Spec completa: /integrar.md.

cole no Claude / Cursor
Integre meu sistema na rede de saúde do WhatsApp Founders (reporte de falhas WhatsApp/Meta).
Leia a spec completa em https://www.whatsappfounders.com.br/integrar.md e implemente no meu projeto.

Minhas credenciais (guarde o WHF_SECRET em variável de ambiente — nunca no código/repo):
  API        = https://api.whatsappfounders.com.br
  WHF_KEY    = whf_live_…        (cole a sua)
  WHF_SECRET = whfsec_…          (cole o seu)
  TENANT     = SEU_TENANT

Comece pelo componente "envio": no caminho de envio, um try/catch que faz POST {API}/v1/ping/{TENANT}/envio/fail (sem ?period) quando o envio dá erro — fire-and-forget, nunca derrube o app. Heartbeat periódico é opcional. Me pergunte quais componentes consigo medir e o que fazer quando houver outage do grupo.
Prompt completo — sem precisar abrir nada
autossuficiente
Você vai integrar meu sistema na rede de saúde do WhatsApp Founders. Implemente no meu projeto, na minha linguagem e convenções.

O QUE É: o jeito mais simples é reportar SÓ falhas — um try/catch nas minhas chamadas à Cloud API que manda um POST quando algo dá erro. Opcionalmente, também mando "heartbeats" de tô-no-ar a cada ~5 min. Em troca recebo alertas de outage do grupo, benchmark anônimo e um selo. A rede NUNCA recebe minhas mensagens nem dados de clientes — só sinais up/fail e contagens agregadas.

CREDENCIAIS (preencha; guarde o secret em env var, nunca no código):
  API        = https://api.whatsappfounders.com.br
  WHF_KEY    = whf_live_…        (público, identifica meu tenant)
  WHF_SECRET = whfsec_…          (SECRET)
  TENANT     = SEU_TENANT

API DE REPORTE:
  POST {API}/v1/ping/{TENANT}/{component}[/fail][?period=600]
  headers: WHF-Key: {WHF_KEY}, WHF-Secret: {WHF_SECRET}
  - com /fail = erro (down); sem /fail = saudável (up)
  - DOIS MODOS: (a) SÓ-FALHA (recomendado) — NÃO mande ?period; faça POST .../{component}/fail quando pegar um erro. Fica down só no /fail explícito, volta sozinho ~30 min depois do último erro (ou na hora se você mandar um up). Sem cron, sem tráfego periódico. (b) HEARTBEAT (opcional) — mande ?period=600 e um ping saudável a cada ~600s; se pararem de chegar, viro "silencioso" (dead-man's-switch).
  - corpo JSON opcional {"error_count":N,"total_count":M} — razão de erro > 25% conta como falha e alimenta o benchmark
  - componentes que EU reporto: envio, recebimento, midia, templates (só os que eu meço; comece por "envio"). NÃO envie qualidade-limites nem plataforma-meta — a rede calcula esses sozinha.
  - respostas: 200 {"ok":true,...} · 401 credencial errada · 403 chave/tenant não batem · 404 componente desconhecido · 429 rate limit (120/min)

TAREFA:
  1. Embrulhe minhas chamadas à Cloud API em try/catch. Em erro no "envio" (e, se eu medir, recebimento/midia/templates), faça um POST {API}/v1/ping/{TENANT}/{component}/fail — fire-and-forget, nunca deixe esse report estourar ou travar o request. Só isso já é uma integração completa (sem cron, sem ?period).
  2. (Opcional) No próximo sucesso, mande o mesmo path SEM /fail pra limpar na hora; senão volta sozinho ~30 min depois do último erro.
  3. (Opcional, só se eu quiser meu próprio uptime % / dead-man's-switch) crie um cron que manda heartbeat com ?period=600 a cada ~5 min.
  4. Leia WHF_KEY/WHF_SECRET de variáveis de ambiente; nunca hardcode o secret.
  5. Toda chamada resiliente: timeout curto, nunca derrube o app se o report falhar, logue não-200.

WEBHOOK (opcional — reagir a outage): registre um receiver em https://www.whatsappfounders.com.br/alertas/ (devolve um webhook secret, diferente do WHF_SECRET). Cada entrega tem:
  X-WHF-Event: incident.opened | incident.resolved
  X-WHF-Signature: sha256=<hex hmac_sha256(webhook_secret, "{timestamp}.{raw_body}")>
  X-WHF-Timestamp: <unix>
  Valide antes de confiar: leia t do header X-WHF-Timestamp; rejeite se |agora - t| > 300s; recalcule hmac_sha256(webhook_secret, "{t}.{raw_body}") sobre o corpo CRU (antes do parse), tire o prefixo "sha256=" do X-WHF-Signature e compare o hex em tempo constante.
  Corpo: {"event","component","status","scope","confidence","contributing_companies","incident_id","occurred_at"}; scope ∈ {meta_platform, group, tenant}.

Me pergunte quais componentes eu consigo medir e o que devo fazer quando houver outage (pausar campanha / failover / avisar on-call), e então implemente.

1 Receba suas credenciais

Ao ativar seu acesso você recebe um par de credenciais (o secret aparece uma única vez — guarde):

  • WHF-Key — identifica seu tenant (whf_live_…)
  • WHF-Secret — autentica seus heartbeats (whfsec_…)

Ainda não tem chave? Ative seu acesso com o código que você recebeu. Trate o WHF-Secret como senha: variável de ambiente no servidor, nunca no navegador nem no front.

2 Reporte falhas (try/catch)

O jeito mais simples e recomendado: um try/catch nas suas chamadas à Cloud API que faz um POST minúsculo quando algo dá erro. Sem corpo, sem biblioteca, sem cron. Comece pelo componente envio — o sinal que mais importa (se não dá pra enviar, você está fora).

Sem ?period, o monitor fica em modo só-falha: só acende no /fail e volta sozinho ~30 min depois do último erro (ou na hora, se você mandar um up). Quer também medir seu próprio uptime %? Veja o modo heartbeat (opcional) abaixo.

no try/catch — troque SEU_TENANT
export API="https://api.whatsappfounders.com.br"
export WHF_KEY="whf_live_…"  WHF_SECRET="whfsec_…"

# pegou erro no envio (sem ?period = modo só-falha)
curl -fsS -X POST "$API/v1/ping/SEU_TENANT/envio/fail" \
  -H "WHF-Key: $WHF_KEY" -H "WHF-Secret: $WHF_SECRET"

# (opcional) limpar na hora, no próximo envio que der certo
curl -fsS -X POST "$API/v1/ping/SEU_TENANT/envio" \
  -H "WHF-Key: $WHF_KEY" -H "WHF-Secret: $WHF_SECRET"
Modo heartbeat (opcional) — uptime próprio / dead-man's-switch
cron a cada 5 min — com ?period=600
# saudável a cada ~5 min:
curl -fsS -X POST "$API/v1/ping/SEU_TENANT/envio?period=600" \
  -H "WHF-Key: $WHF_KEY" -H "WHF-Secret: $WHF_SECRET"
# em falha:
curl -fsS -X POST "$API/v1/ping/SEU_TENANT/envio/fail?period=600" \
  -H "WHF-Key: $WHF_KEY" -H "WHF-Secret: $WHF_SECRET"

Com ?period=600 você declara uma cadência; se os pings pararem de chegar, marcamos sua operação como silenciosa (dead-man's-switch). Útil pra medir seu próprio uptime %.

Resposta: 200 {"ok": true, "component": "envio", "monitor": "default", "status": "up"}status vira "down" no /fail. Erros vêm como {"error":{"code","message","status"}}: 401 credenciais · 403 chave/tenant · 404 componente · 429 rate limit (120/min/tenant — espere alguns segundos). O sinal é idempotente na janela (last-write-wins), então re-tentar um timeout é seguro. Pra confirmar que chegou, GET {API}/v1/me (mesmas credenciais) devolve seus monitores — status · last_ping_at · seconds_since_ping — então dá pra ver se o reporte tá chegando.

Vários números? Use um monitor nomeado por número/linha: /v1/ping/{tenant}/{component}/{nome}[/fail] (o padrão é default). Cada (componente, nome) é rastreado e fica silencioso de forma independente.

3 Métricas por componente avançado · opcional

Quer aparecer no benchmark anônimo? Mande contagens por componente. A cada janela, envie quantos erros sobre o total — por envio, recebimento, midia e templates. Nós cuidamos do anonimato (k-anonimato ≥ 5).

com contagens — vira sinal de erro acima de 25%
curl -fsS -X POST "$API/v1/ping/SEU_TENANT/envio" \
  -H "WHF-Key: $WHF_KEY" -H "WHF-Secret: $WHF_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"error_count": 3, "total_count": 200}'

Você reporta os quatro de mensageriaenvio · recebimento · midia · templates — só os que consegue medir. qualidade-limites e plataforma-meta a rede calcula sozinha (veja Componentes).

Componentes

Seis componentes compõem a saúde do grupo. Você reporta os quatro de mensageria mandando /fail quando detecta problema (e, opcionalmente, up/heartbeats); os outros dois a rede calcula sozinha — você não envia.

envio você reporta
Você consegue enviar mensagens pela Cloud API. O sinal que mais importa — se não dá pra enviar, você está fora.
recebimento você reporta
Os webhooks de recebimento da Meta estão chegando ao seu backend.
midia você reporta
Envio/recebimento de mídia — imagem, documento, áudio, vídeo, figurinha.
templates você reporta
Envio de templates (HSM) — aprovação e entrega.
qualidade-limites a rede calcula
Qualidade e tier de mensageria da conta (quality rating GREEN/YELLOW/RED). Calculado a partir da frota de números do grupo — não envie esse componente.
plataforma-meta a rede calcula
Saúde da plataforma Meta / Cloud API em si. A rede sonda a Meta ativamente (status oficial + probe) — não envie esse componente.

4 Receba alertas no seu backend

Registre um webhook em /alertas/ e seu sistema reage sozinho a outages — pausa campanha, faz failover, avisa o time. Cada entrega é assinada: confira a assinatura antes de confiar. Use o secret do webhook (devolvido ao registrar) — não é o seu WHF-Secret.

cabeçalhos de cada entrega
X-WHF-Event:     incident.opened          # ou incident.resolved
X-WHF-Signature: sha256=<hex>
X-WHF-Timestamp: <unix>

# assinatura = HMAC_SHA256(secret_do_webhook, "<timestamp>." + corpo_cru)
# valide a janela de tempo (anti-replay) e compare em tempo constante

Corpo (CloudEvents) — o campo scope diz se o problema é da Meta, do grupo, ou só seu:

{
  "event": "incident.opened",
  "component": "envio",
  "status": "major_outage",
  "scope": "meta_platform",          // meta_platform | group | tenant
  "confidence": 0.92,
  "contributing_companies": 7,
  "incident_id": "…", "occurred_at": "…"
}

Entrega: mandamos o POST e esperamos 2xx em até 5s. Em timeout/erro/5xx, fazemos até 3 tentativas no total (1 + 2 re-tentativas) com backoff; após 10 falhas seguidas a inscrição é desativada (re-registre em /alertas/). Entrega é at-least-once sem ordem garantida — deduplique por incident_id e responda 2xx rápido (trabalho pesado em background). Campos: confidence float 0–1, contributing_companies int, occurred_at ISO-8601 UTC. Spec completa: /integrar.md.

5 Mostre o selo de status

Um selo via shields.io, sempre atualizado, para README, painel interno ou site. Nosso endpoint devolve o esquema do shields; é só embutir:

status do componente envio
HTML / Markdown
<img alt="status envio"
     src="https://img.shields.io/endpoint?url=https://api.whatsappfounders.com.br/v1/badge/envio">

![status envio](https://img.shields.io/endpoint?url=https://api.whatsappfounders.com.br/v1/badge/envio)

Conceitos & privacidade

Componentes & sinais
Cada sinal é up ou fail em um componente. O grupo só vira incidente com quórum — várias empresas falhando ao mesmo tempo — confirmado pelas sondas que fazemos direto na Meta.
Anonimato (k ≥ 5)
O benchmark só mostra uma faixa quando há pelo menos 5 outras empresas reportando, e as faixas são arredondadas: ninguém vê a taxa exata de ninguém.
Escopo do alerta
meta_platform = caiu na Meta · group = caiu no grupo · tenant = só em você. Seu backend decide o que fazer com cada um.
O que não guardamos
Nunca recebemos suas mensagens nem dados de clientes. Só contagens agregadas (erros/total) e o sinal up/fail. Você manda; nós nunca puxamos.
Feed de incidentes (RSS)
Um feed público (sem auth) dos incidentes recentes — {API}/v1/feed.rss. Jogue num app de RSS do Slack ou qualquer leitor pra uma inscrição sem código.
Versão & suporte
A API é versionada em /v1 e v1 é estável — breaking changes só em nova versão, com aviso. Dúvidas ou problemas de integração: fale na comunidade WhatsApp Founders.