Limites de pedidos

A API de Parceiros permite 300 pedidos por minuto por chave. A janela é um minuto deslizante, e o orçamento pertence à chave e não ao restaurante ou à sua empresa, por isso duas implantações com duas chaves têm dois orçamentos. O endpoint MCP consome o mesmo orçamento: uma chamada de ferramenta é um pedido.

Ultrapassá-lo responde 429 com um documento de problema do tipo rate-limit-exceeded e um cabeçalho Retry-After que indica o número de segundos até o orçamento voltar a encher. Espere que passe; não repita antes, porque um pedido que chega cedo demais consome orçamento sem ter êxito.

Retry-After é o único cabeçalho de orçamento. Não há nenhum X-RateLimit-Remaining para vigiar, por isso regule o ritmo do seu cliente por desenho e não por leitura de um contador — os hábitos abaixo são esse desenho.

Ficar abaixo dele com folga

Três hábitos cobrem quase todas as integrações:

Peça páginas cheias. limit=100 obtém o mesmo dia de entregas com um quarto dos pedidos de que limit=25 precisa. O custo de um pedido é o pedido, não o número de linhas.

Só vá buscar as fotografias quando precisar delas. Uma entrega traz um imageCount. Se for 0, não há nada por trás do endpoint das imagens, e chamá-lo é um pedido gasto numa lista vazia.

Serialize uma recuperação de histórico. Percorrer um ano de histórico com dez processos em paralelo é a única forma que atinge o limite de forma fiável. Um processo com limit=100 atravessa o ano de um restaurante movimentado em poucos minutos.

Se precisar mesmo de mais

Diga-nos qual é a carga de trabalho. O limite existe para impedir que um cliente mal comportado degrade o serviço para o restaurante a quem os dados pertencem, não para racionar o acesso; uma carga de trabalho legítima e descrita é uma conversa, não uma recusa.

Os outros limites que vale a pena conhecer

Estes são impostos pela API, e não apenas descritos por ela: exceder qualquer um dos três primeiros responde 429 ou 400 em vez de truncar em silêncio.