Carrossel automático no Instagram com Claude, GPT-Image e Make

Todo dia de manhã, um carrossel sai no Instagram do lowcode.ai sem eu abrir nada. Um agente busca as notícias, o Claude escolhe uma e escreve os slides, o GPT-Image gera a imagem da capa, o servidor monta as seis imagens e o Make publica. Quando algo dá errado, o motivo aparece no painel.

Este é o passo a passo completo desse carrossel automático no Instagram, etapa por etapa, com os campos, os prompts e os erros que me custaram semanas. Ele foi pensado para quem não é desenvolvedor, mas não pula a parte técnica: os nomes das ferramentas, das tabelas e dos módulos são os reais.

O sistema em uma tabela

O site e o painel foram construídos no Lovable, com Supabase como banco. Cada etapa grava o resultado numa tabela instagram_posts, e a etapa seguinte lê de lá. Essa separação é o que permite que uma etapa falhe sem derrubar as outras.

O que você precisa antes de começar

Você vai precisar de um projeto no Supabase, de chaves de API da Anthropic, da OpenAI e da Brave Search, de uma conta no Make e de uma conta profissional no Instagram (comercial ou de criador) conectada a uma página do Facebook, que é o que o Make pede para conectar o Instagram.

Guarde as chaves como segredos das edge functions do Supabase, nunca no código do front-end. Se o seu projeto foi feito com IA, vale passar antes pelo checklist de segurança do Lovable com Supabase.

Etapa 1: buscar notícias sem repetir pauta

A busca roda numa edge function do Supabase (daily-news-instagram). Ela lê a lista de temas configurada no painel e consulta a Brave Search API para cada um.

Os temas aceitam sinônimos separados por barra vertical. Um tema genérico como "inteligência artificial" traz de tudo, de chip a política pública. Com sinônimos, a busca fica mais perto do público:

vibe coding, inteligência artificial|agentes de IA|IA generativa, SaaS, automação

O rótulo do tema é o primeiro termo antes da barra. É ele que aparece no selo da capa e define a cor de destaque.

Dois cuidados nessa etapa:

1. A Brave entrega só o título e duas ou três frases de cada notícia. Antes de pedir ao Claude para escrever, o sistema baixa o texto completo da página de origem. Sem isso, o modelo preenche lacunas com suposição.
2. Toda notícia usada vai para uma tabela de log (news_automation_log) com a URL e uma assinatura do título. Na próxima busca, qualquer candidata já registrada é descartada. É assim que o mesmo assunto não aparece três dias seguidos vindo de sites diferentes.

Etapa 2: o Claude escolhe a notícia e escreve tudo

Os candidatos vão para o Claude num único pedido. O prompt define a ordem de critérios para a escolha:

1. Aplicabilidade: a notícia muda algo que um criador ou founder brasileiro pode fazer ou decidir nesta semana.
2. Tema pouco usado nas publicações recentes.
3. Atualidade.

A resposta precisa ser um JSON com campos fixos. Este é o formato, com valores de exemplo:

{
  "headline_image": "Título interno do post, até 90 caracteres",
  "cover_hook": "Frase da capa, até 60 caracteres",
  "cover_highlight": "palavras do hook que ganham cor",
  "cover_archetype": "manchete",
  "visual_subject": "a laptop on a dark desk with a glowing server rack behind it",
  "carousel_slides": [
    { "title": "O que aconteceu", "body": "Texto do slide 2" },
    { "title": "Por que importa", "body": "Texto do slide 3" }
  ],
  "caption": "Legenda completa",
  "hashtags": ["automacao", "vibecoding", "nocode"]
}

O ponto que mais melhorou o resultado foi separar o título interno da frase da capa. O cover_hook é escrito para quem está rolando o feed: fala do impacto no leitor, com a palavra-chave no começo. O visual_subject descreve em inglês a cena que representa a notícia. Quem leu a notícia foi o Claude, então é ele que descreve a imagem, e não o modelo de imagem tentando adivinhar a partir do título.

Validação em código, depois da resposta

Nunca confie no JSON sem conferir. O sistema aplica estas regras antes de gravar:

A regra do número é a mais importante. Modelo de linguagem inventa estatística com muita naturalidade, e uma capa com "73%" que não existe na fonte destrói a credibilidade do perfil.

Etapa 3: a imagem da capa com GPT-Image

Aqui está o erro que mais me custou. Na primeira versão, o prompt pedia para o modelo de imagem escrever a manchete na capa. O resultado: cada capa saía com uma tipografia diferente, apareceu uma data inventada ("MAIO/2025") em posts de outubro de 2026, e a cena vinha cheia de textos soltos, como placas e carimbos, competindo com o título.

A regra hoje é simples: o modelo de imagem nunca escreve. Ele gera só a foto, e todo texto é aplicado depois, em código. O final do prompt de imagem tem esta instrução, que prevalece sobre qualquer outra:

Absolutely no text, letters, numbers, logos, signs, stamps, labels or
readable screens anywhere in the image. One large, recognizable central
subject. Keep the lower 45% of the frame darker and visually simple,
and the top 15% clean.

A parte de baixo escura e limpa é onde o título vai entrar. O topo limpo é onde ficam o logo e o selo do tema. A cor do tema também entra no prompt como cor de luz da cena, para a foto conversar com o selo.

Nem toda capa precisa de foto

O sistema trabalha com cinco formatos de capa, e o Claude escolhe um por post:

Variar o formato evita um grid onde todas as capas parecem iguais, e cortar a geração de imagem onde ela não é necessária reduz custo e tempo. A imagem bruta vai para o storage e o post fica marcado com pending_template_render = true, esperando a etapa seguinte.

Etapa 4: montar capa e slides no servidor

Uma rota do próprio site (/api/public/hooks/renderizar-carrosseis) pega até 5 posts pendentes por vez e desenha as imagens com pureimage, uma biblioteca de canvas em JavaScript puro que roda no Cloudflare Workers.

Para a capa, ela desenha a foto de fundo, escurece a parte de baixo em faixas semitransparentes, aplica o selo do tema, o título com o destaque colorido e o logo. Para os slides 2 a 6, ela usa um template fixo com título, texto e paginação. O canto superior direito da capa fica sempre vazio, porque é ali que o Instagram coloca o ícone de carrossel no grid.

Essa rota é chamada de dois jeitos. Logo depois da etapa 3, a edge function dispara a rota uma vez, então o carrossel costuma ficar pronto em poucos minutos. E o banco chama a mesma rota a cada 5 minutos, como rede de segurança:

-- Chama a rota de render a cada 5 minutos (horário em UTC)
select cron.schedule(
  'renderizar-carrosseis-every-5min',
  '*/5 * * * *',
  $$
  select net.http_post(
    url := 'https://seusite.com.br/api/public/hooks/renderizar-carrosseis',
    headers := '{"Content-Type": "application/json", "x-cron-secret": "SEU_SEGREDO"}'::jsonb,
    body := '{}'::jsonb
  );
  $$
);

Antes de desenhar um post, a rota grava render_started_at nele. Se o disparo imediato e o cron chegarem ao mesmo tempo, só um processa o post. Por que essa etapa fica no servidor, e não no navegador, está contado em detalhe em navegador ou servidor: onde gerar as imagens da sua automação. E se a sintaxe do cron ainda é estranha, comece pelo explicador de cron job.

Etapa 5: publicar com o Make

A publicação também começa no Supabase. Uma edge function (publish-scheduled-instagram), chamada por cron a cada 5 minutos, procura posts com horário vencido e imagens prontas e envia cada um para um webhook do Make.

O cenário no Make tem esta estrutura:

1. Webhook personalizado, que recebe o post.
2. Módulo de carrossel do app Instagram for Business, que recebe a lista de URLs das imagens e a legenda.
3. Módulo HTTP que avisa o site que deu certo.
4. Uma rota de tratamento de erro no módulo do Instagram, com outro módulo HTTP que avisa o site que falhou.

O payload que o site manda e o retorno que ele espera:

// O que o site envia para o webhook do Make
{
  "post_id": "uuid do post",
  "image_urls": ["https://.../capa.jpg", "https://.../slide-2.jpg"],
  "caption": "Legenda com hashtags",
  "callback_token": "token secreto deste envio"
}

// O que o Make devolve no callback
{
  "post_id": "uuid do post",
  "success": false,
  "error": "mensagem real do módulo do Instagram",
  "callback_token": "o mesmo token recebido"
}

O token de callback impede que alguém de fora marque posts como publicados. O campo error é onde muita gente tropeça: no meu cenário, a rota de erro mandava "error": "", e o painel só dizia que o Make retornou falha sem motivo. Mapeie a mensagem de erro do módulo do Instagram nesse campo e a próxima falha já vem explicada. Se você está decidindo entre Make e n8n para essa parte, a comparação está em Make vs n8n.

Regras de tentativa

O publicador tenta no máximo 6 vezes. Enquanto as imagens ainda estão sendo montadas, ele não conta tentativa: só espera a próxima rodada, por até 2 horas depois do horário agendado. Sem essa regra, um atraso no render vira uma falha de publicação, que foi exatamente o que acontecia comigo antes.

Erros comuns e como evitar

O que fazer agora

1. Desenhe as cinco etapas no papel e defina qual tabela cada uma lê e grava. Um status por etapa (pending_template_render, scheduled, published, failed) já resolve a maior parte da coordenação.
2. Escreva o prompt do Claude pedindo JSON com campos fixos e implemente a validação da tabela da etapa 2 antes de gerar qualquer imagem.
3. Tire todo texto do prompt de imagem e reserve as áreas do título e do logo com instruções de composição.
4. Coloque o render numa rota de servidor com reserva por render_started_at e agende essa rota no pg_cron.
5. Monte o cenário do Make com rota de erro e callback com mensagem. Teste forçando um erro (uma URL de imagem inválida) e confira se o motivo aparece no painel.
6. Rode a automação manualmente por uma semana, olhando cada post antes de sair, e só então deixe tudo no automático.