REST API WordPress

REST API WordPress é a interface oficial do core que expõe conteúdo e funcionalidades do CMS via HTTP e JSON, permitindo que aplicações externas leiam e gravem dados sem usar o painel wp-admin. Está embutida no WordPress desde a versão 4.7 e é a base de tudo que envolve o editor Gutenberg, integrações com apps mobile, sites headless e qualquer software que precise conversar com o WordPress de forma programática.

O que é a REST API WordPress

REST significa Representational State Transfer. Na prática, é um padrão de arquitetura para APIs onde cada recurso (post, página, usuário, comentário) tem uma URL própria e operações como GET, POST, PUT e DELETE definem o que fazer com ele. O WordPress segue esse padrão e expõe endpoints sob a rota /wp-json/wp/v2/.

Quem busca o que é wp rest api costuma estar tentando entender por que precisa lidar com nonces, autenticação e cabeçalhos JSON em vez de simplesmente clicar em “publicar” no admin. A diferença é que a REST API foi desenhada para máquinas, não para pessoas, e isso muda os padrões de uso.

Antes da REST API, integrações com WordPress dependiam de XML-RPC, um protocolo antigo, lento e difícil de usar. Quando a REST API entrou no core, o WordPress se tornou plataforma viável para arquiteturas modernas: apps React consumindo conteúdo via JSON, sites estáticos gerados por Gatsby ou Next.js, automações em Node.js conectando publicação a outros sistemas.

A api wordpress é extensível. Plugins podem registrar endpoints próprios via register_rest_route, expandindo a API para cobrir custom post types, taxonomias, dados de WooCommerce, métricas internas. Praticamente qualquer dado armazenado no WordPress pode ser exposto, desde que com autenticação e controle de permissão adequados.

Endpoints principais

Os endpoints padrão cobrem os recursos centrais do WordPress. /wp-json/wp/v2/posts retorna os posts publicados em formato JSON, com paginação, filtros por categoria, autor, data e ordenação. É o endpoint mais usado em integrações de leitura de conteúdo.

/wp-json/wp/v2/pages cobre páginas estáticas. /wp-json/wp/v2/users expõe usuários, com proteção contra exposição de emails. /wp-json/wp/v2/categories e /wp-json/wp/v2/tags retornam taxonomias. /wp-json/wp/v2/media lista anexos da biblioteca. Todos seguem o mesmo padrão de URL, paginação e filtros.

Para custom post types, os endpoints são gerados automaticamente quando o tipo é registrado com show_in_rest=true. Um CPT “produto” vira /wp-json/wp/v2/produto. Combine com taxonomias customizadas e hooks bem definidos no Custom Post Type para que tudo apareça organizado na API.

Cada endpoint suporta os métodos HTTP padrão: GET para ler, POST para criar, PUT para atualizar, DELETE para apagar. Os métodos de escrita exigem autenticação. Os de leitura, por padrão, são públicos para conteúdo publicado, e exigem auth para conteúdo restrito como rascunhos e privados.

Autenticação na REST API

Para integrações dentro do mesmo navegador, como o editor Gutenberg, o WordPress usa cookies + nonces. O usuário já está autenticado pelo cookie de sessão, e o cabeçalho X-WP-Nonce confirma que a requisição partiu do site real, não de uma origem cross-site. Esse padrão fecha a maioria dos casos de uso internos.

Para integrações externas (apps mobile, automações server-to-server, ferramentas de terceiros), o caminho é Application Passwords, recurso nativo do WordPress desde a versão 5.6. Cada usuário pode gerar senhas específicas para cada aplicação, com escopo limitado e revogação granular. Combinadas com Basic Auth via HTTPS, são suficientes para a maioria dos cenários.

Para arquiteturas mais sofisticadas, plugins como JWT Authentication for WP-API trazem autenticação via tokens JWT, padrão moderno em APIs profissionais. O cliente faz login uma vez, recebe um token assinado, e usa esse token nos cabeçalhos das requisições seguintes. É o padrão recomendado para apps mobile com volume de tráfego.

OAuth 2.0 é a opção para integrações terceirizadas em escala. Quando uma plataforma externa precisa acessar o site WordPress de vários clientes, OAuth garante autorização com escopo controlado, sem expor credenciais. Plugins como WP OAuth Server cobrem o caso. Lembre-se: nunca exponha endpoints sensíveis sem combinar autenticação com nonce WordPress ou rate limiting.

Casos de uso e exemplos

O caso de uso mais comum é wordpress headless. O WordPress fica como CMS de conteúdo, e o frontend é um app React, Next.js, Vue ou similar que consome via REST API. O usuário final nunca vê o WordPress: vê apenas o app moderno que renderiza os dados. É padrão em sites de mídia, lojas premium e aplicações enterprise.

Outro caso forte são apps mobile. O app no celular do usuário se autentica no WordPress via JWT, lê conteúdo via /posts e /pages, posta novos conteúdos via POST. O WordPress vira backend completo do app, sem precisar de servidor próprio para gerenciar conteúdo.

Automação de fluxos editoriais é outro nicho que cresce. Ferramentas como Make (Integromat) e Zapier consomem a REST API para criar posts automaticamente a partir de planilhas, RSS, transcrições de podcast ou geração com IA. Você publica em um Google Sheets e o post entra como rascunho no WordPress.

Para integrações que envolvem dados sensíveis ou permissões avançadas, o cuidado com vulnerabilidades é redobrado. Endpoints mal protegidos foram causa de várias CVEs históricas em plugins. Sempre valide capability, sanitize input e limite rate em endpoints públicos.

Para projetos que combinam WordPress headless ou integrações via API com necessidade de stack profissional já validada, a FULL Services entrega a stack completa pronta dentro do painel, com hospedagem otimizada para tráfego de API, plugins curados e documentação dos endpoints customizados habilitados. Em vez de configurar autenticação, rate limit e cache de API um por um, o site roda em uma camada validada em produção desde o começo.