NFER
Visão GeralQuick StartAutenticaçãoAmbientesConfiguração InicialExemplos de RequisiçãoGlossário FiscalChecklist de Go-LiveFAQModelo de DadosCiclo de Vida & FluxoContingência AutomáticaLimites & Rate LimitEvitando DuplicidadeErros e RetransmissãoSplit Fiscal HíbridoNovoConceitosEmissão Passo a PassoConceitosEmissão Passo a PassoConceitosEmissão Passo a PassoCódigos de ServiçoConceitosEmissão Passo a PassoNovoRegimes, CST e CFOPEventos FiscaisVisão Geral & CronogramaNovos Campos na APITabela cClassTribDevoluções & AnulaçõesChecklist de MigraçãoVisão Geral & NSUCorporate+NF-e Recebidas & MD-eCorporate+NFS-e Tomadas (ADN)Corporate+CT-e Fretes & DesacordoCorporate+White-Label & Org APIEmpresaCertificado A1 & CSCHabilitação SEFAZCadastrosNumeraçãoPlanos

Limites de Taxa e Rate Limit

Controle de taxa, cabeçalhos informativos, HTTP 429 e estratégias de backoff.

Para garantir alta disponibilidade, justiça no uso de recursos computacionais e proteção contra ataques de negação de serviço (DDoS), a API do NFER aplica controle de taxa de requisições (rate limiting) por chave de API e endereço IP.

Cabeçalhos de Rate Limit

Todas as respostas da API incluem cabeçalhos informativos sobre o consumo da sua cota em tempo real:

Cabeçalho HTTPTipoDescrição
X-RateLimit-LimitIntegerNúmero máximo de requisições permitidas na janela de tempo vigente para o seu plano.
X-RateLimit-RemainingIntegerQuantidade de requisições restantes disponíveis até o final da janela atual.
X-RateLimit-ResetTimestamp UnixMomento exato (em segundos desde a época Unix) em que o contador de requisições será reiniciado.
Retry-AfterInteger (Segundos)Enviado exclusivamente quando o limite é atingido (HTTP 429). Informa quantos segundos seu cliente deve aguardar antes de tentar novamente.

Comportamento no Código HTTP 429

Ao ultrapassar o limite, o servidor recusa requisições adicionais com o código 429 Too Many Requests e payload padronizado:

{ "error": { "code": "RATE_LIMIT_EXCEEDED", "message": "Limite de requisições excedido para o plano atual. Tente novamente em alguns segundos.", "retryAfter": 3 } }

Estratégia Recomendada de Backoff

Ao implementar sistemas que realizam disparos em lote (batch) ou consultas frequentes, siga estas práticas:

  • Respeite o Retry-After: Se a API retornar Retry-After: 3, pause a fila por 3 segundos antes de disparar o próximo item.
  • Backoff Exponencial com Jitter: Em caso de erro temporário, dobre o tempo de espera a cada nova tentativa (ex.: 1s → 2s → 4s) com uma variação aleatória (jitter) para evitar picos sincronizados na rede.
  • Priorize Webhooks: Evite fazer polling contínuo para verificar o status de autorização das notas. Webhooks eliminam a necessidade de chamadas repetitivas.

Limites e Cotas por Plano

Os limites de requisições por minuto e as cotas mensais de notas emitidas variam de acordo com o plano contratado. Consulte a tabela detalhada de limites em Planos & Limites.

Próximos Passos

AnteriorContingência AutomáticaPróximoEvitando Duplicidade