Mapa da trilha
Conteúdo detalhado
🐘 WordPress REST API
O WordPress roda em 43% dos sites do mundo e expõe uma REST API completa em /wp-json/wp/v2/. Publique posts, mídia, categorias e agendamentos sem plugin extra.
Desde a versão 4.7 (2016), a REST API vem habilitada por padrão. Endpoint base: https://seusite.com/wp-json/wp/v2/.
Sem configuração extra. Basta saber a URL e ter credenciais. Funciona em hospedagens compartilhadas, VPS e WordPress.com Business+.
GET /wp-json retorna discovery, JSON estruturado, mesmo schema de admin, alguns plugins de segurança bloqueiam — verificar antes.
Senha de aplicação gerada em Usuários → Perfil → Application Passwords. Formato: xxxx xxxx xxxx xxxx xxxx xxxx (24 chars, 6 grupos).
Substitui a senha real. Revogável individualmente. Habilitada nativamente desde WordPress 5.6 — não precisa de plugin JWT.
Header: Authorization: Basic base64(user:app_pass). Cada app gera uma senha diferente. Logs no Site Health.
Endpoint que recebe JSON com title, content, status, excerpt, slug, author. Retorna o post criado com ID.
É o endpoint nuclear. Domina ele e domina a publicação automatizada inteira: blog post, página, custom post type — todos seguem o mesmo padrão.
Content-Type: application/json, content aceita HTML, retorna 201 Created, ID retornado serve para PUT/DELETE futuros.
Endpoint multipart que aceita arquivos. Headers: Content-Disposition: attachment; filename="foto.jpg" e Content-Type: image/jpeg. Body = bytes do arquivo.
Post sem imagem destacada parece amador. Faça upload primeiro, pegue o ID retornado, depois passe em featured_media no POST do post.
Aceita JPG, PNG, WebP, MP4, PDF. Retorna ID + URL. Anexa ao post via featured_media: ID. Alt text via PATCH posterior.
Endpoints /wp-json/wp/v2/categories e /wp-json/wp/v2/tags. No POST do post, passe arrays de IDs: categories: [3, 5], tags: [7, 9, 12].
Organização e SEO. Categoria sem tag = post órfão. Crie taxonomias antes de publicar — ou GET para listar IDs existentes.
IDs numéricos (não slugs), criar via POST nos endpoints específicos, slug é único, parent permite hierarquia em categorias.
Campo status aceita: publish (público), draft (rascunho), future (agendado — exige date ISO 8601), private, pending.
Permite agendar dezenas de posts de uma vez. Combine status: future + date: 2026-12-25T10:00:00 para publicação automática no Natal.
Date no fuso configurado no WP, future precisa de WP-Cron ativo, draft não vai pro feed RSS, private só autor enxerga.
👻 Ghost Admin API
O Ghost é o CMS minimalista feito para publicação. Sua Admin API usa JWT e tem SDK oficial. Limpa, rápida, sem o legado do WordPress.
No painel Ghost: Settings → Integrations → Add custom integration. Gera Admin API Key, Content API Key e API URL.
É o único caminho oficial para automação. Cada integration tem chaves separadas — revogáveis sem afetar outras.
Admin API = escrita, Content API = leitura pública, webhook opcional, ícone customizável para identificar.
String no formato {id}:{secret}. Ex: 5f9e...3a:abc123def.... O id identifica a integration, o secret assina o JWT.
Diferente de tokens simples: você não envia a key, você usa ela para gerar JWT a cada requisição. Mais seguro.
Split em :, id vira kid no JWT, secret é hex → Buffer para assinar HS256, nunca commitar.
SDK oficial: npm i @tryghost/admin-api. Métodos prontos: api.posts.add(), .edit(), .browse(), .delete().
Cuida do JWT automaticamente. Você só passa URL, key e versão. Reduz 50 linhas de auth para 3.
Versão da API obrigatória (ex: v5.0), suporta source HTML/Markdown/Lexical, retorna Promise.
Cada request gera um JWT HS256 com payload {iat, exp: iat+5min, aud: "/admin/"}, header com kid, assinado com o secret hex.
Mesmo se interceptado, o token expira em 5 min. Em outras linguagens (Python, Go), você implementa essa lógica manualmente.
Header: Authorization: Ghost <jwt> (não "Bearer"!), HS256, kid no header, hex → Buffer no Node.
No posts.add({...}, {source: 'html'}), o campo html é convertido para o formato Lexical interno. Sem o source, Ghost espera Lexical JSON.
HTML é universal — qualquer Markdown renderiza pra HTML. Você escreve no formato que quiser, Ghost armazena no formato dele.
Status: published/draft/scheduled, title obrigatório, slug auto-gerado, tags como array de objetos [{name: "tag"}].
Campos: feature_image (URL), meta_title, meta_description, og_title, og_description, twitter_image, canonical_url.
Ghost já gera Open Graph e Twitter Card automaticamente — mas dá pra customizar por post. Diferença entre 100 cliques e 1000.
Upload da imagem em POST /images/upload primeiro, URL retornada vai em feature_image, canonical evita penalização SEO.
✍️ Dev.to & Hashnode
Plataformas focadas em devs. Dev.to (Forem) usa REST simples; Hashnode usa GraphQL. Ambas têm comunidade ativa e SEO forte para conteúdo técnico.
Token gerado em dev.to/settings/extensions → DEV Community API Keys. Use header api-key: SEU_TOKEN (não Bearer).
Sem chave, sem publicação. É um único token por conta — perdeu, regenera (invalida o anterior).
Base URL: https://dev.to/api, header customizado api-key, rate limit ~10 req/30s, formato JSON.
Endpoint POST https://dev.to/api/articles. Body: {article: {title, body_markdown, published, tags, ...}}. Dev.to roda em cima do Forem open-source.
Mesmo endpoint funciona em qualquer Forem (Dev.to, CodeNewbie, etc). Aprende uma vez, usa em várias plataformas.
Tudo dentro de article: {}, published bool, tags array de strings (máx 4), markdown nativo, retorna URL do post.
Dev.to aceita YAML frontmatter dentro do body_markdown: ---\ntitle: ...\ncover_image: https://...\nseries: ...\n---.
Permite criar séries (capítulos linkados), definir cover image, canonical URL, tudo no próprio markdown. Útil pra cross-posting de Hugo/Jekyll.
cover_image deve ter 1000x420px, series string agrupa posts, canonical_url evita duplicate content, published: false = draft.
Endpoint único: POST https://gql.hashnode.com. Body: {query, variables}. Auth: header Authorization: PAT_TOKEN (gerado em settings/developer).
GraphQL retorna exatamente os campos pedidos — sem over-fetching. Schema tipado, autocomplete em ferramentas tipo Apollo.
Query vs Mutation, publicationId obrigatório (id do blog), Personal Access Token (PAT), errors no response não sobem como HTTP error.
Mutation: mutation PublishPost($input: PublishPostInput!) { publishPost(input: $input) { post { id slug url } } }. Input com publicationId, title, contentMarkdown, tags.
É a forma oficial de publicar. updatePost e removePost seguem padrão idêntico — aprende uma mutation, conhece todas.
Tags array de {slug, name}, coverImageOptions opcional, originalArticleURL pra cross-post, retorna post completo.
Tag HTML <link rel="canonical"> aponta pro post "original". Quando você publica o mesmo conteúdo em vários sites, só o canonical recebe crédito SEO.
Sem canonical, Google considera duplicate content e pode rebaixar todos. Com canonical, você ganha alcance sem perder ranking.
Dev.to: canonical_url, Hashnode: originalArticleURL, WordPress: plugin Yoast, sempre apontar pro seu domínio próprio.
📂 Sites estáticos via GitHub API
Hugo, Jekyll, Astro, Next.js — todos viram blog estático. Commit no GitHub via API = deploy automático pelo GitHub Actions. Velocidade absurda e custo zero.
Static Site Generators: lê arquivos Markdown + templates → HTML estático. Hugo (Go, mais rápido), Jekyll (Ruby, GitHub Pages nativo), Astro (JS, modern), Next.js (React, híbrido).
HTML estático = CDN-friendly, escala infinita, custo zero, sem banco de dados, sem PHP, imune a 99% das vulnerabilidades web.
Posts vivem em content/posts/ ou _posts/, build local com CLI, deploy automatizado, themes customizáveis.
Token gerado em github.com/settings/tokens. Prefira "Fine-grained tokens": permite escolher repos específicos e escopo Contents: read+write.
Sem PAT você não escreve via API. Fine-grained limita o estrago se vazar — só funciona no repo escolhido.
Header: Authorization: Bearer ghp_xxx, expiração configurável (90 dias recomendado), nunca commitar, usar GitHub Secrets em Actions.
Endpoint: PUT https://api.github.com/repos/{owner}/{repo}/contents/{path}. Body: {message, content: base64(markdown), branch}.
É como fazer git commit sem ter git instalado. Funciona de qualquer lambda, Edge Function ou n8n.
Content em base64 obrigatório, message vira mensagem do commit, sha necessário pra editar arquivo existente (não criar), retorna SHA do novo commit.
Bloco YAML entre --- no início do .md: title, date, draft, tags, image. Hugo/Jekyll/Astro leem isso pra montar metadata.
Formato universal entre todos os SSGs — migrar de Hugo pra Astro = só trocar build, conteúdo continua igual.
date em ISO 8601, draft: true esconde do build, slug opcional (usa filename), TOML também aceito (+++).
Workflow em .github/workflows/deploy.yml roda em push: build do SSG → upload pro GitHub Pages, Netlify, Vercel ou Cloudflare Pages.
Commit via API → push trigger → build → deploy. Em 60 segundos seu post está no ar globalmente. Zero intervenção manual.
on: push, jobs com runs-on, actions oficiais (actions/checkout, actions/deploy-pages), secrets pra tokens.
Sem banco, sem PHP, sem painel admin. Conteúdo versionado em Git. Hospedagem grátis (Pages/Netlify/Vercel) ou ~$1/mês em CDN.
Performance 10x melhor que WordPress. Segurança nativa (sem superfície de ataque). Custo ~zero. Versionamento incluído.
Trade-off: sem dinâmico (comments via Disqus), sem painel não-técnico, build pode demorar em sites grandes, ótimo para blog/docs/portfolio.