Como extrair dados de restaurantes e cardápios do iFood? Scraper vs API

Você quer responder uma pergunta aparentemente simples: como extrair dados de restaurantes e cardápios do iFood?

Talvez o objetivo seja montar um dashboard de inteligência competitiva, monitorar preço de pizza por bairro, acompanhar taxa de entrega de concorrentes, enriquecer uma base de restaurantes ou alimentar um agente de IA com dados verificáveis. No papel, parece direto: abrir o site, buscar por um CEP, pegar a lista de restaurantes, entrar em cada loja e salvar o cardápio em JSON.

Na prática, esse é o tipo de projeto que começa como “faço em um fim de semana” e termina virando uma operação de web scraping iFood, reverse engineering, validação de dados, fila de execução, monitoramento e manutenção contínua.

Este guia vai fazer o caminho completo: primeiro, vamos pensar como alguém que tentaria criar o próprio scraper iFood em Python. Depois, vamos mostrar onde a abordagem quebra. No fim, a conclusão honesta: se o seu objetivo é ter dados de restaurantes, cardápios, preços, entrega e avaliações em produção, a saída mais curta costuma ser usar uma API para iFood como a GeckoAPI.

O que significa extrair dados do iFood

Antes de escrever qualquer linha de código, defina o dado que você precisa. “Extrair iFood” pode significar várias coisas diferentes:

Objetivo	Dados desejados
Listar restaurantes por região	nome, categoria, nota, distância, status, taxa de entrega
Extrair cardápio iFood	seções, itens, descrições, preços, promoções, imagens
Monitorar concorrentes	posição na busca, disponibilidade, pedido mínimo, tempo de entrega
Criar BI de food delivery	histórico por CEP, bairro, keyword e categoria
Enriquecer base comercial	URL pública da loja, slug, merchantId, endereço e coordenadas

Em termos de produto de dados, existem dois movimentos principais:

Busca/listagem de restaurantes, normalmente por keyword + CEP ou por latitude/longitude.
Detalhe da loja, onde aparecem merchant, cardápio, preços, horários, pagamento e dados operacionais.

Na GeckoAPI, esses dois movimentos são tratados como PLP e PDP:

iFood PLP para descobrir restaurantes por região e termo de busca.
iFood PDP para extrair dados completos da loja e do cardápio.

Mas vamos começar sem API pronta, porque é assim que quase todo projeto nasce.

Primeira tentativa: scraper simples com requests

O primeiro impulso de qualquer dev é tentar uma requisição HTTP simples. Você escolhe uma URL pública de restaurante, baixa o HTML e procura os dados.

import requests
from bs4 import BeautifulSoup

url = "https://www.ifood.com.br/delivery/sua-cidade/sua-loja/exemplo"

headers = {
    "User-Agent": (
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/124.0 Safari/537.36"
    )
}

resp = requests.get(url, headers=headers, timeout=30)
resp.raise_for_status()

soup = BeautifulSoup(resp.text, "html.parser")

print(soup.title.get_text(strip=True) if soup.title else "sem title")
print(resp.text[:500])

Em alguns sites, isso já resolve. O HTML vem server-side rendered, o preço está em uma tag previsível, os dados aparecem em JSON-LD e você parseia tudo com BeautifulSoup.

No iFood, esse caminho tende a ser bem menos estável. O que você pode encontrar:

HTML inicial sem o cardápio completo.
Conteúdo carregado por JavaScript.
Dados dependentes de localização.
Loja disponível para uma região e indisponível para outra.
Campos que mudam conforme canal, contexto, horário e método de entrega.
IDs internos necessários para buscar detalhes do cardápio.

Ou seja: o scraper simples até pode baixar alguma coisa, mas raramente entrega o que você realmente queria: dados estruturados de restaurante e cardápio do iFood em escala.

Segunda tentativa: Playwright ou Puppeteer

Quando requests não basta, o próximo passo é emular um navegador real. Com Playwright, você consegue abrir a página, esperar o JavaScript rodar e tentar ler o DOM final.

from playwright.sync_api import sync_playwright

def extrair_texto_da_loja(url: str) -> str:
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
        page.goto(url, wait_until="networkidle", timeout=60000)
        texto = page.locator("body").inner_text(timeout=10000)
        browser.close()
        return texto

conteudo = extrair_texto_da_loja(
    "https://www.ifood.com.br/delivery/sua-cidade/sua-loja/exemplo"
)

print(conteudo[:2000])

Isso parece uma vitória: agora você vê restaurante, itens, talvez preço e seções do cardápio. Só que transformar “texto visível no navegador” em um pipeline confiável é outra história.

Você ainda precisa resolver:

como definir a localização da busca;
como persistir contexto de CEP sem usar conta pessoal;
como paginar resultados de restaurantes;
como abrir cada loja sem perder contexto;
como expandir seções e itens do cardápio;
como detectar item indisponível;
como diferenciar preço atual, preço original e complementos;
como saber se o dado salvo está completo;
como lidar com mudanças de layout.

Um browser headless ajuda a enxergar a página. Ele não transforma automaticamente o iFood em uma API.

O ponto em que vira reverse engineering

Se você continuar investigando, vai abrir a aba Network do navegador e observar as chamadas que alimentam a interface. Esse é o ponto em que o projeto deixa de ser um “scraperzinho” e vira reverse engineering de aplicação web.

Em alto nível, você precisaria entender:

quais endpoints alimentam busca, loja, cardápio e item;
quais parâmetros representam localização, merchant, catálogo e canal;
quais headers e tokens são contextuais;
quais respostas mudam por horário, região e disponibilidade;
como validar que o menu retornado pertence ao restaurante correto;
como lidar com retry, cache, paginação e respostas parciais.

Não é uma boa ideia criar um produto em cima de tentativa e erro com endpoint interno, sessão de usuário, login, CAPTCHA ou qualquer mecanismo de controle de acesso. Além de frágil, isso pode criar risco jurídico e operacional. O caminho responsável é trabalhar com dados publicamente acessíveis, minimizar coleta, respeitar termos aplicáveis e não coletar dados pessoais desnecessários.

Na prática, para extrair restaurantes e cardápios do iFood com consistência, você não está só “fazendo scraping”. Você está mantendo uma integração não documentada com uma plataforma grande, dinâmica e sensível a contexto.

E a API oficial do iFood?

Existe documentação oficial do iFood Developer para integrações com o ecossistema iFood. Ela é importante para parceiros, sistemas de gestão, operações de restaurante, pedidos, catálogo e fluxos homologados.

Mas esse não é o mesmo caso de uso de quem quer fazer pesquisa de mercado, monitoramento de concorrentes, extração de restaurantes por CEP ou coleta de cardápios públicos em escala. A API oficial de parceiro não é uma API aberta de leitura irrestrita para consultar qualquer loja pública por keyword, região e URL como um motor de inteligência competitiva.

Então, se você busca no Google por:

“como extrair dados do iFood”
“scraper iFood Python”
“web scraping iFood restaurantes”
“extrair cardápio iFood”
“API iFood restaurantes e cardápios”

é provável que o seu problema não seja integração operacional como parceiro. O seu problema é transformar dados públicos do marketplace em JSON confiável.

Por que um scraper iFood quebra em produção

O protótipo normalmente funciona em uma loja, em uma máquina, em uma tarde. O problema aparece quando você tenta rodar todo dia, para dezenas de CEPs, keywords e restaurantes.

1. Localização muda tudo

Delivery é geográfico. O mesmo restaurante pode aparecer para um CEP e não aparecer para outro. Taxa, tempo, disponibilidade e até composição do cardápio podem variar por localização.

Um scraper que ignora geografia gera dados bonitos, mas pouco úteis.

2. Cardápio não é só nome e preço

Um item de cardápio pode ter:

nome;
descrição;
preço atual;
preço original;
imagem;
tags;
disponibilidade;
complementos;
opções obrigatórias;
observação;
contexto da loja.

Se você extrai apenas o texto visível da página, pode perder justamente as partes que importam para análise de preço e comparação de oferta.

3. DOM scraping é frágil

Seletores como .restaurant-name, .dish-card ou button:nth-child(3) parecem práticos até o primeiro deploy do site-alvo. Uma mudança visual pequena pode quebrar todo o parser.

Quando isso acontece, o pior cenário não é o scraper parar. O pior cenário é ele continuar rodando e salvar dados errados.

4. Browser headless custa caro

Playwright e Puppeteer são excelentes ferramentas, mas cada navegador consome CPU, memória e tempo. Para uma coleta pequena, tudo bem. Para milhares de restaurantes e cardápios, a conta cresce rápido.

Você acaba construindo:

fila de execução;
controle de concorrência;
pool de browsers;
retries com backoff;
detecção de resposta incompleta;
logs e alertas;
storage de snapshots;
comparação histórica.

O projeto deixa de ser “extrair dados do iFood” e vira “manter uma infraestrutura de scraping”.

5. O dado precisa ser auditável

Para BI, pricing e inteligência competitiva, não basta capturar qualquer coisa. Você precisa saber:

quando o dado foi extraído;
de qual URL ou contexto veio;
qual CEP ou coordenada foi usado;
se a loja estava aberta;
se o cardápio estava completo;
se o campo estava ausente ou se o parser falhou.

Essa camada de auditoria costuma ser esquecida no MVP e cobrada quando o dashboard começa a influenciar decisão de negócio.

Checklist realista para fazer do zero

Se você ainda quiser construir seu próprio scraper iFood, trate como projeto de engenharia, não como script descartável.

Você vai precisar de:

Camada	O que implementar
Descoberta	Busca por keyword, CEP, coordenadas e paginação
Detalhe	Extração de loja, merchant, cardápio e itens
Normalização	Campos padronizados para preço, entrega, nota e status
Validação	Checagem de respostas vazias, parciais ou inconsistentes
Persistência	JSONL, banco relacional ou data lake com histórico
Observabilidade	Logs, métricas, alertas e amostras para auditoria
Manutenção	Testes de parser e monitoramento de mudança no upstream
Compliance	Sem login indevido, sem dados pessoais desnecessários, coleta responsável

Essa lista não é para assustar. É para alinhar expectativa. Se a sua empresa quer aprender web scraping, pode ser um bom projeto técnico. Se a sua empresa quer dados do iFood para tomar decisão, talvez você esteja resolvendo o problema errado.

A alternativa: GeckoAPI para iFood

A GeckoAPI entrega os dados do iFood como JSON estruturado, usando endpoints pensados para o fluxo real de extração:

PLP para buscar restaurantes por keyword + zipCode ou por latitude/longitude.
PDP para extrair dados completos de uma loja a partir da URL pública.
IDP para detalhes de item quando você precisa aprofundar complementos e opções.

O resultado é que você troca semanas de engenharia reversa por uma chamada HTTP.

Buscar restaurantes por CEP e keyword

import requests

API_URL = "https://api.geckoapi.com.br/v1/extract"
API_KEY = "SUA_CHAVE_AQUI"

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json",
}

payload = {
    "target": "ifood.com.br",
    "type": "plp",
    "keyword": "hamburguer",
    "zipCode": "01310-100",
    "page": 1,
}

resp = requests.post(API_URL, json=payload, headers=headers, timeout=60)
resp.raise_for_status()

data = resp.json()

for loja in data["data"]["items"]:
    print(loja["name"], loja.get("userRating"), loja.get("distanceKm"), loja["url"])

Com isso, você consegue descobrir restaurantes por região, salvar URL pública, posição, avaliação, distância e dados de entrega para alimentar sua base.

Extrair cardápio completo de uma loja

def extrair_cardapio_ifood(url_loja: str) -> dict:
    payload = {
        "target": "ifood.com.br",
        "type": "pdp",
        "url": url_loja,
    }

    resp = requests.post(API_URL, json=payload, headers=headers, timeout=90)
    resp.raise_for_status()
    return resp.json()

detalhe = extrair_cardapio_ifood(data["data"]["items"][0]["url"])
loja = detalhe["data"]["data"]

print(loja["name"])
print(loja.get("minimumOrderValue"))

for secao in loja["menu"]:
    print("##", secao["name"])
    for item in secao["items"]:
        print(item["name"], item.get("price"), item.get("originalPrice"))

Agora você tem o que o scraper prometia entregar, mas sem depender de seletor visual, browser headless ou endpoint interno descoberto manualmente.

O que você consegue construir com esses dados

Com dados de restaurantes e cardápios do iFood em JSON, os casos de uso aparecem rápido:

Monitoramento de preços iFood por item, categoria, bairro e concorrente.
Inteligência competitiva para restaurantes com comparação de taxa, tempo e pedido mínimo.
Radar de cardápio para detectar novos combos, promoções e itens removidos.
Análise de expansão por CEP, densidade de concorrência e disponibilidade.
BI para food delivery com snapshots históricos e alertas operacionais.
Agentes de IA e chatbots que respondem com dados verificáveis em vez de suposições.

Esse é o ponto central: o valor não está em provar que você consegue abrir o iFood com Playwright. O valor está em transformar dado de delivery em decisão.

Scraper próprio vs GeckoAPI

Critério	Scraper próprio	GeckoAPI
Tempo até primeiro dado útil	Dias ou semanas	Minutos
Manutenção de parser	Sua equipe	Abstraída pela API
Browser headless	Provável	Não necessário no seu lado
Normalização de resposta	Você implementa	JSON estruturado
Escala por CEP e keyword	Exige infraestrutura	Chamada HTTP
Auditoria de extração	Você desenha	`executionId`, origem e timestamps
Foco do time	Scraping e manutenção	Produto, BI e análise

Se a sua vantagem competitiva é vender software de scraping, construir internamente faz sentido. Se a sua vantagem competitiva é pricing, growth, BI, pesquisa de mercado ou operação de restaurantes, usar uma API pronta provavelmente fecha melhor a conta.

Perguntas frequentes

É possível fazer scraping do iFood com Python?

É possível prototipar partes do fluxo com Python, requests, Playwright ou Puppeteer. O problema é transformar isso em coleta estável de restaurantes, cardápios e preços em produção. A dificuldade real está em localização, dados dinâmicos, validação, manutenção e escala.

Dá para extrair cardápio do iFood sem API?

Até dá para tentar por navegação automatizada ou engenharia reversa, mas o resultado tende a ser frágil. Cardápio inclui seções, itens, preços, promoções, disponibilidade e complementos. Se você precisa desses campos com confiabilidade, uma API estruturada reduz bastante o risco.

A API oficial do iFood resolve monitoramento de concorrentes?

Não como uma API aberta de inteligência de mercado. A documentação oficial do iFood Developer atende fluxos homologados do ecossistema de parceiros. Para consultar restaurantes públicos por região, keyword e URL de loja, você precisa de outra abordagem.

Qual é o melhor formato para salvar dados do iFood?

Para MVP, JSONL funciona bem: uma linha por restaurante ou snapshot de cardápio. Para produção, vale persistir em banco com histórico por merchantId, zipCode, keyword, extractedAt, preço e disponibilidade.

Quais campos devo monitorar primeiro?

Comece por name, url, position, userRating, distanceKm, deliveryInfo, minimumOrderValue, menu[].items[].name, price, originalPrice e disponibilidade. Esse conjunto já sustenta dashboards úteis de preço, entrega e concorrência.

Conclusão: o scraper ensina, a API entrega

Construir um scraper iFood é um bom exercício para entender web moderna: localização, renderização, APIs internas, cardápio dinâmico, dados contextuais e manutenção de parser. Mas como estratégia de negócio, ele cobra caro.

Você começou querendo saber como extrair dados de restaurantes e cardápios do iFood. A resposta técnica é: dá para tentar, mas o caminho confiável exige web scraping sério, reverse engineering cuidadoso, infraestrutura e manutenção constante.

A resposta prática é mais simples: use a GeckoAPI para iFood, receba restaurantes e cardápios em JSON estruturado e coloque sua energia na análise.

Pronto para testar? Acesse dashboard.geckoapi.com.br e comece a extrair dados do iFood com uma chamada HTTP.