Há dois contratos distintos: o MCP OAuth para operar recursos do Wellbhook conforme a identidade e as permissões; e a API/MCP legados, por chave, para consultar check-ins e eventos de integração.
/mcp. Use um cliente MCP que suporte OAuth e conclua o login interativo. O Wellbhook deriva a conta vinculada, a organização, o papel e os grants; um ID de aluno ou nome enviado pelo agente não prova identidade.WELLBHOOK_API_KEY ao cliente. Essa chave serve para /api/v1 e o endpoint legado /api/mcp; não autentica o MCP de operações em /mcp.O catálogo de /mcp aplica escopos OAuth e permissões atuais em toda chamada; escritas dependem de wellbhook.write, cliente permitido e papel/grants. A chave da API legada não amplia esse acesso. Nenhum dos fluxos processa pagamentos de alunos.
Extraia o ZIP. A pasta wellbhook/ reúne a skill de integração de check-ins e os pacotes locais para Codex e Claude Code. Revise os arquivos antes de instalar. Para operações da academia, configure separadamente o MCP OAuth em https://wellbhook.com.br/mcp.
Copie wellbhook/skills/wellbhook-integration/ para .agents/skills/ do seu projeto. Abra uma nova sessão e peça para usar a skill wellbhook-integration.
Adicione https://wellbhook.com.br/mcp nas configurações MCP de um cliente que ofereça OAuth interativo e conclua o vínculo pelo login do Wellbhook. Não configure aqui a chave de API legada para obter ferramentas de gestão.
O plugin local é para a skill e a integração legada de check-ins; ele não configura o MCP operacional OAuth:
claude --plugin-dir ./wellbhook
Invoque /wellbhook:wellbhook-integration. Para usar a gestão pelo MCP, registre separadamente o endpoint OAuth em um cliente compatível; a disponibilidade no Claude web/Desktop não está homologada.
Guarde a chave legada com um gerenciador de segredos; nunca a cole em prompts, arquivos versionados ou comandos no histórico. Não reutilize essa chave como token OAuth.
Endpoint: https://wellbhook.com.br/mcp, com transporte Streamable HTTP e identidade OAuth validada no servidor (issuer, audiência, expiração, revogação, vínculo e escopo). O catálogo público e as anotações não concedem autorização. Nenhuma conexão real com cliente é declarada homologada por esta página.
| Ferramenta | Como ajuda |
|---|---|
get_daily_brief, list_sessions | Consulta o resumo operacional e sessões da unidade, filtrados por papel, grant e fuso local. |
list_weekly_schedule_rules, search_members | Gestores consultam recorrências e equipe permitida; dados são limitados à unidade/organização autorizada. |
get_my_schedule, get_my_membership, get_my_credit_balance | Autosserviço deriva aluno/dependente do principal e dos vínculos verificados; não aceita ID arbitrário como identidade. |
book_my_session, cancel_my_booking | Reservas próprias seguem regras de crédito, prazo e capacidade e exigem escopo de escrita e cliente autorizado. |
preview_*, apply_approved_* | Operações administrativas sensíveis dependem de prévia persistida, aprovação distinta na web, versão atual e revalidação ao executar. |
Ferramentas de escrita só são anunciadas conforme o token OAuth validado, o cliente registrado/permitido e o escopo wellbhook.write; o backend ainda revalida papel, vínculo e regras. Ações de aluno/responsável derivam a identidade do principal autenticado. Alterações sensíveis não aceitam autoaprovação pelo agente.
O Wellbhook não processa nem intermedeia pagamento de aluno: sem checkout, Pix, cartão, recorrência ou gateway. O único fluxo de pagamento processado pelo produto é Organização → Wellbhook, pela assinatura SaaS.
/api/v1 e /api/mcp continuam disponíveis para check-ins/eventos de integração, com WELLBHOOK_API_KEY revogável e escopo de leitura da academia/ambiente. O MCP legado oferece list_checkins, list_events e get_integration_guide; esse contrato não gerencia alunos, planos ou agenda e não autentica /mcp.
Um evento registrado não comprova a entrega HTTP ao receptor. Confira estado/tentativas em Webhooks. A integração ou instalação da skill não habilita nem homologa Wellhub/TotalPass; disponibilidade em ChatGPT ou Claude web/Desktop também depende de teste e política do cliente.
Este roteiro é para integrações legadas de check-ins e webhook, não concede acesso administrativo à academia. O agente deve adaptar a persistência e os testes à arquitetura do sistema.
Integre o Wellbhook ao sistema desta academia. 1. Leia a skill wellbhook-integration e o guia de integração. 2. Implemente um receptor HTTPS que verifique HMAC-SHA256 sobre timestamp + "." + corpo original, com tolerância de 5 minutos e comparação em tempo constante. 3. Persista o evento e deduplique por id em uma transação. Não dependa da ordem de entrega. Responda 2xx somente após persistência durável, inclusive para duplicados. 4. Separe DEMO de LIVE e preserve a identificação do provedor. 5. Teste assinatura inválida, replay, duplicidade e reenvio. 6. Use o MCP para consultar os eventos da demonstração e explique como configurar o destino no painel. Use variáveis de ambiente para os segredos. Não coloque chaves em código, mensagens, commits ou logs. Não trate um check-in aprovado como passagem comprovada por catraca.
WELLBHOOK_WEBHOOK_SECRET no seu servidor.Webhooks podem chegar fora de ordem e mais de uma vez. Preserve o ID para deduplicação, aceite versões conhecidas do envelope e mantenha transições de estado consistentes. A resposta 2xx confirma o recebimento persistido do evento; não deve esconder uma falha ao salvar.
Estes arquivos públicos documentam a API de leitura de check-ins e a construção de receptores; não são a referência de autenticação ou catálogo do MCP OAuth operacional.
Confirme que conectou /mcp, que o cliente concluiu o fluxo OAuth e que a identidade está vinculada a uma conta Wellbhook ativa. A chave WELLBHOOK_API_KEY serve somente para API/MCP legado e não substitui OAuth.
Para o contrato legado, confira a chave, o ambiente, a unidade, o período e a paginação. A chave DEMO consulta apenas dados DEMO; simulação gera dados fictícios.
O servidor filtra ferramentas por escopo OAuth, cliente, papel e autorização atual. Solicite acesso pelo fluxo administrativo. Repetir a chamada com outro ID ou alegar outro canal não concede permissão.
O MCP operacional exige suporte a Streamable HTTP e OAuth. A compatibilidade e a política de cada cliente precisam ser verificadas separadamente; esta implementação local não comprova homologação externa.