RECURSOS · META ADS
Limites de cota (erro 613) na API da Meta Ads
Explica por que as ferramentas que consultam a API ao vivo colapsam e por que uma arquitetura com cache noturno garante disponibilidade total.
Resposta rápida
O erro 613 da API da Meta Ads indica que o limite de chamadas foi excedido. O limite é calculado sobre as chamadas da última hora em relação aos usuários ativos e à cota por conta. A forma de evitar é armazenar os dados em cache e atualizá-los em uma janela controlada, não consultar ao vivo cada vez que alguém abre um relatório.
Pontos principais
- O erro 613 é um problema de arquitetura, não de sorte.
- Consultas ao vivo multiplicam chamadas a cada visita.
- Um cache noturno com TTL de 26 horas mantém o relatório disponível.
Neste guia
O que significa o erro 613
A Meta aplica um limite de taxa por aplicação e por conta. Quando o volume de chamadas em uma janela móvel excede a cota, a API retorna o erro 613 e para de responder até a janela liberar. Para uma agência, isso significa relatórios vazios ou desatualizados justamente quando o cliente precisa.
O problema piora porque muitas ferramentas consultam a API cada vez que um relatório é aberto. Se dez pessoas abrem o mesmo cliente em uma hora, geram dez vezes as mesmas chamadas.
- O limite é dinâmico e depende do volume de usuários.
- Consultas repetidas consomem cota mesmo quando retornam os mesmos dados.
- Tentativas agressivas pioram a situação.
A arquitetura que evita o colapso
A solução é separar atualização de visualização. Um processo noturno consulta as APIs, guarda o resultado em um banco de dados e atribui um vencimento. Durante o dia, o relatório é servido desse cache, sem tocar na API.
Com frequência diária e TTL de 26 horas, cada cliente é consultado uma vez por dia e o relatório continua disponível mesmo se a atualização atrasar. O custo em chamadas fica previsível.
- Atualização programada em uma janela de baixa demanda.
- Cache por cliente com vencimento maior que o ciclo de atualização.
- Servir o relatório do banco de dados, não da API.
O que fazer quando o limite já foi atingido
Se o erro aparecer, é preciso reduzir chamadas, não aumentá-las. Pause as tentativas automáticas, use a última cópia disponível e espere a janela liberar. Também vale revisar se há processos duplicados ou consultas que podem ser agrupadas.
Um sistema de alertas deve distinguir entre dado antigo e dado inexistente. Mostrar a última atualização com a data é melhor do que mostrar um erro ou um zero.
- Parar tentativas e processos duplicados.
- Servir a última cópia válida com data visível.
- Revisar a janela de atualização e o volume de chamadas.
- Agrupar consultas por conta quando possível.
Como a Clarika resolve
A Clarika atualiza os dados em uma janela noturna, guarda em cache e serve os relatórios do banco de dados. A agência e o cliente podem abrir o mesmo relatório muitas vezes sem gerar uma única chamada adicional à Meta.
A arquitetura também inclui tentativas controladas e alertas de saúde da conexão. O objetivo não é apenas evitar o erro 613: é fazer o relatório estar disponível quando alguém o abre, mesmo se a API estiver tendo um dia ruim.
- Cache noturno por cliente.
- TTL de 26 horas para cobrir atrasos.
- Relatórios servidos em milissegundos.
Perguntas frequentes
O erro 613 é permanente?
Não. É temporário e se libera quando a janela de taxa reinicia. O problema é que, enquanto dura, a ferramenta não consegue atualizar dados. A prevenção é arquitetônica.
Um cache mostra dados desatualizados?
Mostra o último dado consolidado, que em um relatório mensal costuma ser suficiente. A chave é que a data de atualização esteja visível e que o ciclo noturno seja confiável.
A Clarika consulta a API ao vivo?
A atualização roda em uma janela programada e o relatório é servido do cache. Assim se evitam consultas repetidas a cada visita.
Relatórios disponíveis mesmo quando a API falha
Teste uma arquitetura com cache noturno e pare de depender de consultas ao vivo.
Continue lendo
Conteúdo relacionado para aprofundar.