Como criar rascunho WordPress com n8n pela API

Para criar rascunho WordPress com n8n pela API, use uma conexão autenticada, envie o conteúdo com status draft e consulte o post salvo antes de declarar a entrega concluída. Se houver capa nova, envie a mídia e vincule seu ID ao post. Guarde os identificadores para retomar uma falha sem começar a criação novamente.

Defina o que significa entregar um rascunho

Comece pelo contrato do pacote: título, corpo HTML, resumo, slug, categoria, tags, capa e metadados aplicáveis. Um processo que só registra “post criado” não distingue uma entrega completa de outra que perdeu a imagem ou recebeu o conteúdo de uma pauta diferente. Defina quais campos precisam coincidir com os arquivos aprovados antes de configurar o nó que grava.

Separe produção editorial e importação. Na recomendação editorial deste guia, o fluxo recebe arquivos conferidos e grava somente rascunhos. A publicação continua sendo uma decisão posterior, tomada sobre o conteúdo que efetivamente ficou salvo. Se um agente participa da redação, não deixe que ele escolha livremente o status do post ou substitua a aprovação dos arquivos por uma mensagem de conclusão.

Autenticação: conta, senha de aplicação e site correto

A documentação de autenticação do WordPress apresenta Application Passwords para acesso remoto à REST API com Basic Auth sobre HTTPS. Para esse caminho, utilize o login da conta e a senha de aplicação correspondente, preservando a validação do certificado. O nome dado à aplicação não é o nome de usuário.

No n8n, a credencial WordPress pede Username, application Password e WordPress URL no modo Basic Auth. A documentação também descreve OAuth2 para WordPress.com. Identifique qual ambiente você tem: não aplique automaticamente as telas e requisitos de WordPress.com a uma instalação própria.

Antes da primeira gravação, faça uma conferência de leitura no site e no tipo de conteúdo previstos. Verifique a identidade autenticada e as permissões necessárias para criar o rascunho e enviar mídia. Uma conexão aceita não demonstra que o usuário consegue realizar toda a entrega. Também não trate a senha de aplicação como um mecanismo que, sozinho, restringe o fluxo a rascunhos.

Mantenha o segredo na credencial do n8n, sem inseri-lo no texto, no pacote editorial ou em exemplos publicados. Confira o endereço usado em cada requisição para não reutilizar uma credencial em outro site por engano. Se houver falha de certificado, investigue a conexão; habilitar uma opção que ignora SSL não deve ser a solução padrão para uma integração editorial.

Nó WordPress ou HTTP Request: escolha pelos campos necessários

O nó WordPress oferece operações de criação, consulta e atualização de posts. Quando a operação necessária não estiver disponível, o n8n orienta usar HTTP Request com a API do serviço. Confira as opções expostas no nó da sua versão, em vez de classificar um caminho como profissional e o outro como limitado por definição.

O HTTP Request permite configurar método, autenticação, corpo, headers e opções de resposta. Para este processo, ele pode ser adequado quando você precisa chamar uma rota de mídia, um tipo de conteúdo próprio ou um endpoint de plugin. Essa flexibilidade exige que você confira o contrato de cada rota.

Nas duas alternativas, preserve o resultado de cada etapa. Se o nó de mídia devolve um ID e o nó seguinte substitui o item de entrada pela resposta do post, seu controle precisa manter ambos. Organize nomes e referências para distinguir ID editorial, ID do post e ID da capa. Não use um campo genérico chamado “id” como se sempre representasse o mesmo recurso.

Posts comuns e CPTs podem usar rotas diferentes

Para posts comuns, a referência de Posts da REST API documenta criação em POST /wp/v2/posts e consulta por ID. O caminho é relativo à raiz da API, normalmente /wp-json/. O payload pode incluir título, conteúdo, resumo, slug, status, taxonomias e featured_media.

Para um tipo próprio, a documentação de CPTs na REST API explica show_in_rest e rest_base. O nome interno do tipo pode ser diferente da base da rota. Confirme a rota registrada no site antes de escolher o endpoint ou assumir que o nó de posts atende a esse conteúdo.

Um blog pode ter posts tradicionais e uma coleção própria de artigos. Criar na coleção errada ainda pode produzir uma resposta válida, mas o conteúdo pode ficar fora do arquivo e do template esperados. Inclua tipo e rota na identificação do trabalho. Na retomada, consulte o mesmo recurso; encontrar um título parecido em outra coleção não comprova que a importação desejada já aconteceu.

Imagem destacada: envie a mídia ou reutilize um ID existente

A referência de Media documenta criação em POST /wp/v2/media, consulta e campos como alt_text, source_url e media_details. Para vincular uma imagem destacada, use o ID da mídia em featured_media. Uma URL de foto não substitui esse identificador.

Se a imagem já existe e é a correta, você pode reutilizar seu ID. Para um arquivo novo, confira antes formato, dimensões, composição e nome. Na requisição de upload, configure o envio do arquivo binário de acordo com o contrato da rota e com a opção do HTTP Request. Não confunda o nome de uma propriedade binária do n8n com o conteúdo efetivo do arquivo.

Depois do upload, consulte a mídia e confira o que foi servido: arquivo acessível, formato esperado, dimensões e alt. Para imagens dentro do corpo, o HTML precisa apontar para a URL que o leitor consegue carregar. Um caminho local do computador pode funcionar na produção do pacote e continuar inválido no site. O fluxo deve resolver essas referências antes de enviar o post.

Grave o ID da capa assim que a etapa for confirmada. Se a gravação do post falhar, uma retomada não deve reenviar automaticamente a mesma imagem. A recomendação editorial é manter um registro por arquivo e verificar a biblioteca quando o resultado do upload for incerto. Nome determinístico ajuda na busca, mas não é garantia suficiente de que o arquivo encontrado seja o mesmo.

Crie com draft explícito e confira os campos

Uma entrada mínima de exemplo poderia ser a seguinte. O título e o slug são ilustrativos; acrescente os IDs e campos do pacote aprovado, conforme o recurso escolhido. Mantenha o status fixo no fluxo.

{
  "title": "Artigo de demonstração",
  "slug": "artigo-de-demonstracao",
  "status": "draft",
  "content": "<p>Corpo aprovado do artigo.</p>",
  "excerpt": "Resumo aprovado do artigo."
}

Após obter o ID, faça uma consulta autenticada ao post e use o contexto de edição quando tiver acesso aos valores de origem. Compare o conteúdo salvo com o enviado, junto com título, resumo, status, imagem e taxonomias. Se alguma extensão sanitizar ou transformar o HTML, investigue a diferença antes de marcar a entrega como pronta.

Defina uma política para divergência: interromper, registrar o campo afetado e devolver o pacote para ajuste. Não substitua uma validação de texto e imagem por uma checagem de que o ID é numérico. O post pode existir e ainda estar incompleto, em outro estado ou com uma combinação de arquivos que não foi aprovada.

Para a revisão editorial, confira também o HTML renderizado e a prévia do tema: imagem, links, tabelas, card e leitura no celular. Acesso à REST API não cria automaticamente uma sessão de navegador autenticada para abrir rascunhos. Registre o que foi conferido por API e o que ainda depende de uma prévia disponível ao responsável.

Prevenção de duplicados: título e slug não bastam

Título pode mudar, repetir palavras ou identificar trabalhos diferentes. Use uma identidade editorial estável, combinando pauta, pacote e site de destino conforme seu processo. Associe essa identidade ao ID retornado e consulte esse registro antes de criar novamente. Se houver um post publicado relacionado, a rotina precisa de uma decisão explícita sobre atualização, sem sobrescrever o conteúdo automaticamente.

Buscar o slug pode ajudar na recuperação, mas a função wp_unique_post_slug() informa que não faz verificação de unicidade para posts ainda em draft ou pending. Não trate o slug de rascunho como uma restrição de banco que impede duas criações concorrentes.

Como desenho editorial, duas execuções da mesma importação precisam de coordenação: registrar que o trabalho está em andamento, localizar IDs existentes e resolver conflitos antes de outro POST. Se a arquitetura exige garantia forte, implemente e teste esse controle no serviço responsável. A sequência “buscar e depois criar” possui etapas separadas; não deve ser anunciada como execução única garantida.

Se houve timeout durante a criação, não interprete a falta de resposta como ausência do post. Confira o destino usando a identidade disponível e registre o resultado como confirmado, ausente ou incerto. Repetir o envio sem essa distinção pode criar outra cópia. Uma falha posterior ao upload da capa também não implica que aquela mídia precise ser recriada.

SEO e metadados dependem do que o site expõe

O WordPress documenta campos registrados na REST API por mecanismos como register_rest_field e register_meta. Enviar uma chave arbitrária no JSON não demonstra que um plugin a aceita ou que ela ficou salva. Confira os campos e endpoints próprios disponíveis no seu site.

Separe tags, palavra-chave de foco, título SEO, descrição e schema. Depois da gravação, procure uma forma de ler cada valor relevante. Quando um plugin aceita a escrita, mas não oferece leitura pelo acesso existente, registre a limitação. Também não confunda gravação dos campos com cálculo de uma nota de SEO: o processo do analisador precisa ser verificado por seus próprios resultados.

Checklist de recuperação e entrega

• Confirmar site, usuário, tipo de conteúdo e rota antes da gravação.
• Conferir o pacote e fixar o status draft.
• Guardar identidade editorial e IDs de cada recurso.
• Reutilizar mídias confirmadas em retomadas.
• Consultar o post salvo e comparar os campos obrigatórios.
• Tratar timeout como resultado incerto até conferir o destino.
• Verificar comportamento de concorrência com um ambiente controlado.
• Registrar edição, prévia, resultado e pendências reais.

Teste com pacote fictício e site de teste antes de ampliar a rotina. Inclua falha antes da mídia, falha depois da mídia, recusa da API, resultado incerto e duas tentativas do mesmo trabalho. Anote quais recursos ficaram criados em cada caso. Um fluxo que funciona apenas quando todas as etapas têm sucesso ainda não demonstra uma recuperação confiável.

Perguntas frequentes

Recebi um ID. Posso declarar o artigo pronto?

O ID permite localizar o recurso retornado. Consulte-o e confira a entrega editorial exigida. Existência do post e correção de conteúdo, estado, imagem e metadados são verificações diferentes.

Posso criar no CPT usando o endpoint de posts?

Confira a rota exposta pelo tipo de conteúdo. Posts comuns e CPTs podem ter bases diferentes; uma gravação na coleção errada não atende à estrutura editorial desejada.

É preciso enviar uma imagem nova a cada tentativa?

Reutilize o ID quando a mídia existente estiver confirmada e corresponder ao arquivo aprovado. Se o resultado anterior foi incerto, investigue a biblioteca antes de duplicar o upload.

O fluxo pode publicar depois de criar o rascunho?

Somente quando isso fizer parte de uma ação autorizada e validada. Para a rotina descrita aqui, a entrega termina no rascunho conferido e disponível para revisão humana.

Próximo passo: validar uma entrega completa

Comece com um artigo e uma capa, acompanhe cada ID e compare o resultado salvo com o pacote aprovado. Depois teste a recuperação de falhas e a repetição do trabalho. A integração deve reduzir tarefas de importação sem perder a identificação do conteúdo, o controle do estado e a responsabilidade pela revisão.