Feed de produtos para agentes de IA: os nove campos que a OpenAI exige antes de vender seu item

O catálogo agora tem um leitor que não é humano

A OpenAI publica em developers.openai.com/commerce/specs/feed a especificação de feed de produtos que alimenta o comércio por agentes: o esquema de dados que um assistente dentro do ChatGPT lê para buscar, recomendar e, quando a integração de checkout está habilitada, comprar um item em nome de alguém. Não é um rascunho de intenção. É um schema versionado, com uma versão Stable (a que vale para upload de arquivo em produção hoje) e uma versão Draft (publicada só para planejamento, ainda sem suporte em produção).

Para quem cuida de catálogo, CRM ou e-commerce, isso muda a pergunta de sempre. Não basta o produto estar bonito na vitrine do seu site. Ele precisa estar legível para um agente que não vê imagem bonita, lê campo por campo e rejeita a linha inteira se um valor estiver fora do formato esperado.

Os nove campos que abrem a porta da descoberta

A especificação chama de "basic product data" o conjunto mínimo que toda linha do feed precisa ter para ser útil em busca. São nove campos obrigatórios, um por item ou por variação:

Um exemplo mínimo que já passa na validação:

{
 "item_id": "MUG-350-BLUE",
 "title": "Blue ceramic mug, 350 mL",
 "description": "Dishwasher-safe glazed ceramic mug with a handle.",
 "url": "https://example.com/products/mug-blue",
 "brand": "Northline",
 "seller_name": "Northline Home",
 "image_url": "https://example.com/images/mug-blue.jpg",
 "price": "18.00 USD",
 "availability": "in_stock"
}

O detalhe que decide se o agente te acha: disponibilidade

A especificação é direta num ponto que costuma passar batido no cadastro: campo omitido, vazio ou com valor não reconhecido em availability rejeita a linha inteira, não só aquele campo. E unknown só é válido quando usado de propósito, para dizer "não sei o estoque agora". Ele não significa "em estoque" por omissão.

Isso derruba uma prática comum de quem exporta catálogo de um ERP antigo: deixar o campo de estoque em branco achando que o sistema vai assumir "disponível" por padrão. No feed da OpenAI, em branco é erro de validação, não suposição a favor do vendedor.

Preço sem moeda não é preço válido

O campo price espera valor e moeda no mesmo texto, como 79.99 USD. Quem só manda o número, ou usa símbolo de moeda solto, corre risco de rejeição silenciosa na importação. Para loja que opera em mais de um país ou vende em marketplace internacional, isso obriga a revisar se o exportador do catálogo já concatena moeda e valor antes de gerar o arquivo, em vez de deixar essa junção para depois.

Variantes: cada tamanho é uma linha, mas todas apontam para a mesma família

Tênis número 38 e número 40 são itens diferentes para o agente, mas pertencem à mesma "listagem". A especificação resolve isso com quatro campos que trabalham juntos:

• group_id: o ID estável da família de produto, compartilhado por todas as variações (e que precisa ser diferente de cada item_id)
• listing_has_variations: true em toda linha que tem variação; omitido, vazio ou false significa que não há opções
• variant_dict: um objeto simples mapeando o nome da opção ao valor escolhido, como {"color":"Black","size":"10"}
• offer_id: identifica a oferta daquele vendedor especificamente, e nunca deve carregar o preço dentro do próprio ID

Um par de linhas de variante, no formato que o feed espera (uma linha JSON por item, aqui expandida para leitura):

{
 "item_id": "TRAIL-BLK-10",
 "group_id": "TRAIL",
 "listing_has_variations": true,
 "variant_dict": {"color": "Black", "size": "10"},
 "offer_id": "northline-TRAIL-BLK-10",
 "title": "Trail running shoes, black, size 10",
 "description": "Waterproof trail shoes with a rubber outsole and mesh lining."
}

Um erro recorrente em cadastros migrados de planilha é usar o mesmo nome de opção escrito de formas diferentes entre as variações ("Cor" numa linha, "color" na outra). A especificação exige nomes de opção consistentes dentro do mesmo grupo, senão o agente não consegue montar a família de produto corretamente.

GTIN: o dígito verificador que dá para calcular na mão

O campo gtin aceita um identificador de 8, 12, 13 ou 14 dígitos, com dígito verificador válido e sem espaço ou traço. A especificação até ensina a conferir: multiplique os dígitos alternados (começando da direita, antes do dígito verificador) por 3 e por 1, some tudo, e o dígito verificador é o que falta para o total fechar um múltiplo de 10.

No exemplo que a própria OpenAI usa, 09506000134352, a soma dos 13 primeiros dígitos ponderados dá 78. Para chegar ao múltiplo de 10 mais próximo (80), falta 2, que é exatamente o último dígito do código. Vale rodar essa conta antes de subir o feed: GTIN com dígito verificador errado derruba a linha inteira, e planilha herdada de fornecedor é a fonte número um desse erro.

Onde a maioria dos cadastros falha antes mesmo de chegar nas variantes

A seção de "convenções de valor" da especificação lista regras que parecem óbvias e, mesmo assim, são a causa mais comum de rejeição:

1. String de preenchimento tipo null, unknown escrito à toa ou n/a não vale como valor, exceto nos campos onde unknown é explicitamente permitido
2. Campo vazio não significa zero nem false; se o valor é desconhecido, o campo deve ficar de fato omitido
3. Booleano aceita só true ou false em JSON, ou as mesmas palavras em minúscula em arquivo delimitado; qualquer outra grafia não é válida
4. URL de produto e de imagem precisa ser HTTP ou HTTPS absoluta e publicamente acessível, com preferência por HTTPS
5. Em CSV, célula com vírgula, aspas ou quebra de linha precisa vir entre aspas, com cada aspas interna duplicada

A vitrine lida por IA não suspende o Código de Defesa do Consumidor

A especificação reserva um bloco próprio para frete, devolução e avaliações, além dos blocos de mercado, anúncios e checkout. O checkout, aliás, exige uma integração habilitada à parte: ter o feed certo garante que o produto apareça na busca do agente, não que ele já esteja liberado para venda automática.

Aqui está o ponto que interessa a quem responde pelo jurídico da loja: se um agente de IA lê seu feed, recomenda o produto e conduz uma compra, a obrigação de informar prazo de arrependimento, política de troca e condição real de devolução continua sendo da loja vendedora, não da OpenAI. O que estiver cadastrado no bloco de devolução do feed precisa bater, dígito por dígito, com o que o setor de atendimento pratica quando o cliente liga reclamando. Divergência entre o que o agente promete e o que a operação cumpre vira passivo de CDC, com o agravante de ter sido uma máquina quem prometeu.

A flag que liga e desliga a visibilidade do produto

Um campo opcional merece atenção de quem decide o que entra ou sai da vitrine agentic: is_eligible_search. Com true, o item fica elegível para busca; com false, ele sai tanto da busca quanto do checkout. Se o campo vem omitido ou vazio, o padrão é true. Vale lembrar que elegibilidade não garante exibição: é condição necessária, não suficiente.

O que testar na próxima atualização de catálogo

Antes de gerar o próximo arquivo de feed, vale rodar uma checagem simples em três frentes. Primeiro, quantos SKUs têm price com moeda explícita e availability preenchido com um dos cinco valores aceitos, e não vazio. Segundo, quantos GTINs passam no teste do dígito verificador antes de subir o arquivo, em vez de descobrir o erro só no relatório de rejeição. Terceiro, se o texto do bloco de devolução do feed é o mesmo que o atendimento humano aplica hoje no balcão ou no chat.

O número para acompanhar depois que o feed estiver no ar é a taxa de rejeição de linhas na importação, comparada entre a primeira carga e a carga seguinte. Queda nessa taxa mês a mês é o sinal mais direto de que o cadastro está realmente pronto para ser lido por quem não é gente.

Fonte: OpenAI Developers: Agentic Commerce, especificação do feed de produtos