API ServerDo.in v2

Autenticação

A API pública usa credenciais provisionadas por projeto, assinatura HMAC e proteção contra repetição. A API local usa um token armazenado no próprio servidor.

Headers da API pública

A string canônica é formada por horário, nonce, chave de idempotência e SHA-256 do corpo JSON, separados por quebra de linha. O segredo nunca deve ser enviado na requisição ou gravado em logs.

TIMESTAMP + "\n" + NONCE + "\n" + IDEMPOTENCY_KEY + "\n" + SHA256(CORPO_JSON)

Coloca um lote de URLs na fila de renovação dos servidores de CDN associados ao projeto. Publicações e atualizações devem usar purge_urls.

purge_site é uma ação excepcional, manual e sujeita a permissão específica. Nunca use limpeza completa como fallback para erro, chave desconhecida ou falha parcial.

{
  "operation": "purge_urls",
  "domain": "portal.exemplo",
  "urls": [
    "https://portal.exemplo/",
    "https://portal.exemplo/noticia/"
  ],
  "reason": "publish"
}

Resposta

{
  "status": "queued",
  "operation_id": "ID_DA_OPERACAO",
  "created": true,
  "status_url": "/api/v2/cache/operations/ID_DA_OPERACAO"
}

Repetir a mesma solicitação com a mesma Idempotency-Key devolve a operação existente e não cria uma segunda limpeza.

Cada credencial pode criar até 30 lotes por minuto e 300 por hora. Um lote automático aceita no máximo 40 URLs. Quando o limite é atingido, a API retorna HTTP 429 com Retry-After.

A consulta também exige uma assinatura HMAC nova, corpo vazio e nonce ainda não utilizado. Os estados possíveis são queued, processing, success, partial e failed.

{
  "status": "success",
  "operation_id": "ID_DA_OPERACAO",
  "objects_found": 4,
  "objects_deleted": 4,
  "nodes": [
    {
      "status": "success",
      "objects_found": 2,
      "objects_deleted": 2
    }
  ]
}

A resposta pública não informa nomes internos de servidores, IPs, caminhos de arquivos ou comandos executados.

O endpoint local é a entrada preferencial para projetos habilitados: recebe o lote rapidamente, coordena o Cache Local e encaminha a renovação pública sem manter o jornalista aguardando a conclusão. Ele requer token provisionado no servidor.

curl -X POST \
  "https://controle.portal.exemplo/_serverdoin/v2/cache/purge" \
  -H "Authorization: Bearer TOKEN_LOCAL" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ID_UNICO" \
  --data '{
    "operation": "purge_urls",
    "urls": [
      "https://portal.exemplo/",
      "https://portal.exemplo/noticia/"
    ]
  }'

A disponibilidade do endpoint local depende da habilitação do projeto. A ausência desse recurso não autoriza usar limpeza integral como contingência.

O aquecimento do Cache Local e do CDN é executado pela ServerDo.in. O projeto envia apenas o inventário de URLs por conjunto, liga ou desliga cada camada, define a velocidade e acompanha a execução. A cobertura no CDN segue a política da ServerDo.in: capa, listagens e sitemaps, conteúdos publicados nas últimas 72 horas, imagens das páginas importantes e páginas mais acessadas são sempre aquecidos; o acervo integral só entra enquanto houver espaço. Endereços dos pontos de presença não são expostos.

Todas as rotas usam a mesma assinatura HMAC v2 da renovação de cache (X-ServerDo-Key-Id, X-ServerDo-Timestamp, X-ServerDo-Nonce, Idempotency-Key e X-ServerDo-Signature). Em GET, o corpo assinado é vazio. O parâmetro opcional domain precisa coincidir com o domínio da credencial.

curl -X POST \
  "https://cdnmanager.serverdo.in/api/v2/cache/warm/jobs" \
  -H "X-ServerDo-Key-Id: KEY_ID" \
  -H "X-ServerDo-Timestamp: 1789950000" \
  -H "X-ServerDo-Nonce: NONCE_UNICO" \
  -H "Idempotency-Key: ID_UNICO" \
  -H "X-ServerDo-Signature: ASSINATURA_HMAC" \
  -H "Content-Type: application/json" \
  --data '{
    "layer": "both",
    "rate_rps": 0.5,
    "reason": "Aquecimento após publicação",
    "manifest": {
      "sets": [
        { "name": "core", "urls": ["https://portal.exemplo/", "https://portal.exemplo/ultimas-noticias/"] },
        { "name": "recent_72h", "urls": ["https://portal.exemplo/noticia-recente/"] },
        { "name": "images_recent", "urls": ["https://portal.exemplo/wp-content/uploads/2026/09/capa.jpg"] },
        { "name": "popular", "urls": ["https://portal.exemplo/materia-mais-lida/"] },
        { "name": "archive", "urls": ["https://portal.exemplo/materia-antiga/"] }
      ]
    }
  }'

• layer: local, cdn ou both. Cada camada gera uma fila própria e pode ser pausada, retomada ou cancelada separadamente.
• rate_rps: requisições por segundo, decimal, entre 0.02 e 20 (0.1 equivale a uma requisição a cada 10 segundos). Presets: 0.1, 0.5, 1, 2 e 5. O intervalo vale para requisições que podem consultar a origem; a confirmação de HIT não consulta a origem.
• manifest.sets[]: até 12 conjuntos e 80.000 URLs do próprio domínio. Os nomes core, recent_72h, images_recent, popular, event e archive têm prioridade fixa; outros nomes aceitam priority de 1 a 5.
• variants: site e mobile por padrão. Imagens e arquivos estáticos não variam por dispositivo.
• Sem ponto quente identificado, a fila do CDN fica em queued com o aviso awaiting_traffic até o tráfego do projeto tornar um ponto elegível.
• Renovações confirmadas pela API v2 reenfileiram automaticamente as URLs invalidadas como conjunto event quando a camada está ligada.

Plugin CDN ServerDo.in 2.2.2

A versão 2.2.2 implementa o contrato da API v2 e mantém compatibilidade temporária com projetos ainda não provisionados.

• Publicar ou atualizar conteúdo nunca solicita limpeza integral automática.
• As URLs relacionadas são deduplicadas e limitadas por domínio e período.
• Home, matéria, categorias, taxonomias, autor e URLs adicionais seguem a configuração do projeto.
• O cliente usa HMAC-SHA256, nonce, idempotência, HTTPS e validação TLS.
• A entrega 202 queued é registrada para acompanhamento posterior.
• Perfis desconhecidos, falhas de nó ou erros de DNS não são convertidos em purge_site.

O clique em Publicar/Atualizar não deve aguardar a conclusão da CDN. Nos projetos com bridge local v2, a entrega é feita à fila durável do próprio servidor; a fila do WordPress permanece apenas como contingência durante a migração.

Os recursos são habilitados individualmente após a validação das capacidades do projeto. Se a versão do servidor, os módulos ou o serviço local necessário não forem compatíveis, o plugin mantém o recurso desativado e orienta o responsável a procurar o suporte da ServerDo.in.

Perfil de chave serverdoin-v3

O perfil atual separa páginas HTML para desktop e mobile. Arquivos estáticos não variam por dispositivo.

$cache_uri preserva o caminho original antes do processamento interno do WordPress. $c_uri preserva parâmetros funcionais e remove parâmetros de campanha conhecidos que não devem criar cópias extras do cache. A API rejeita perfis desconhecidos; ela não converte esse caso em limpeza completa.

Ativa, configura ou desativa a conversão de imagens no projeto. O modelo preferencial é entregar AVIF quando aceito pelo navegador, usar WebP como fallback e preservar o arquivo original para clientes sem suporte.

A imagem original é mantida. As versões convertidas podem ter dimensão máxima, como 1800x1800, preservando a proporção. Quanto mais formatos forem gerados, maior será o uso de disco do projeto.

curl -X POST \
  "https://controle.portal.exemplo/_serverdoin/image-optimizer?action=configure" \
  -H "Authorization: Bearer TOKEN_LOCAL" \
  -H "Content-Type: application/json" \
  --data '{
    "enabled": true,
    "preferred_format": "avif_webp",
    "quality": 82,
    "max_dimension": 1800
  }'

curl \
  "https://controle.portal.exemplo/_serverdoin/image-optimizer?action=status" \
  -H "Authorization: Bearer TOKEN_LOCAL"

curl -X POST \
  "https://controle.portal.exemplo/_serverdoin/image-optimizer?action=disable" \
  -H "Authorization: Bearer TOKEN_LOCAL"

Códigos de erro