Dependências externas em sites WordPress: como gerir APIs e integrações de terceiros

Um site WordPress moderno raramente funciona de forma independente. Tem integrações com CRMs, plataformas de email marketing, gateways de pagamento, APIs de maps, chat ao vivo, analytics, heatmaps, e mais. Cada uma destas integrações é um ponto de falha potencial que a agência não controla directamente — mas pelo qual é responsável quando algo corre mal.

O que é uma dependência externa num site WordPress

Uma dependência externa é qualquer serviço ou recurso fora do servidor do site que é necessário para o site funcionar correctamente:

• APIs de terceiros: Google Maps, Stripe, PayPal, MBWay, Multibanco, Mailchimp, HubSpot, ActiveCampaign
• Serviços de CDN: Cloudflare, Bunny, CloudFront para assets estáticos
• Plataformas de email transacional: SendGrid, Mailgun, SMTP externo
• Scripts de terceiros carregados no frontend: Google Analytics, Meta Pixel, scripts de chat (Intercom, Tidio), heatmaps (Hotjar)
• Webhooks e integrações Zapier/Make: automatizações que enviam dados entre o site e outros serviços
• Serviços de autenticação: Google OAuth, integração com sistemas de SSO

Como as dependências externas causam problemas

O serviço externo fica indisponível

Quando o Mailchimp tem downtime, os formulários de subscrição do site ficam a falhar. Quando a API do Stripe tem problemas, o checkout do WooCommerce retorna erros. Estas falhas são confundidas frequentemente com problemas do site — e a agência recebe a chamada.

O serviço externo depreca a API

APIs evoluem e versões antigas são deprecadas. O Google deprecou a API v3 do Maps, o Facebook deprecou múltiplas versões da Graph API, o Stripe actualizou o protocolo de webhooks. Se o plugin que integra com esse serviço não for actualizado a tempo, a integração quebra silenciosamente.

Scripts de terceiros abrandam o site

Cada script externo carregado no frontend (analytics, pixels, chat) adiciona latência. Se o domínio externo que serve o script está lento ou tem problemas, o site fica lento ou bloqueia o carregamento. Não é um problema do site — mas o utilizador e o cliente percebem-no como tal.

Chaves de API expiram ou são revogadas

Chaves de API têm frequentemente prazo de validade ou podem ser revogadas por violação de termos. Uma chave de API de Google Maps expirada significa que todos os mapas do site deixam de carregar — silenciosamente, sem erro no frontend.

Como fazer inventário de dependências externas

O primeiro passo é saber exactamente quais as dependências activas em cada site. Um método prático:

1. Verificar plugins instalados com integração externa: cada plugin que conecta a um serviço externo é uma dependência (WooCommerce + gateway, Contact Form + CRM, etc.)
2. Analisar os scripts carregados no frontend: em Chrome DevTools → Network, filtrar por scripts externos. Identificar domínios de terceiros que são carregados em cada página.
3. Verificar configurações wp-config e opções do site: chaves de API, endpoints e tokens são frequentemente guardados em wp-config.php ou nas opções do WordPress.
4. Documentar na ficha técnica do site: lista de integrações, serviços externos, chaves de API (com data de expiração se aplicável) e contacto do serviço.

Monitorização de dependências externas

Além de monitorizar se o próprio site está online, faz sentido monitorizar as integrações críticas:

• Status pages dos serviços críticos: Stripe, PayPal, Cloudflare, Google, Mailchimp têm páginas de status públicas. Subscrever alertas destas páginas avisa antes que os clientes reportem problemas.
• Monitorização de endpoints críticos: configurar alertas específicos para as funcionalidades mais críticas (verificar se o checkout processa, se os formulários enviam) em vez de apenas monitorizar se o site carrega.
• Testes de funil transacional: para lojas WooCommerce, executar periodicamente um teste de checkout completo detecta problemas de integração antes dos clientes os encontrarem.

Quando uma dependência externa falha: como responder

O protocolo quando uma integração de terceiro falha é diferente de quando o problema é interno:

1. Confirmar que a falha é externa: verificar a status page do serviço. Se confirma downtime ou degradação, a falha não é da agência.
2. Comunicar ao cliente com contexto: "O problema está localizado no serviço X, que está com problemas técnicos. Não está no nosso controlo mas estamos a acompanhar o estado de resolução."
3. Implementar fallback se possível: mensagem de erro amigável em vez de erro técnico visível, funcionalidade alternativa temporária.
4. Acompanhar resolução e validar: quando o serviço externo fica disponível, validar que a integração do site retomou funcionamento normal.