Consumo indevido (excesso de consultas)

O que significa esta rejeição

A SEFAZ identificou que o emitente está fazendo consultas em excesso aos seus webservices, e aplicou um throttling temporário. O "consumo indevido" é a SEFAZ dizendo "você está consultando a mesma coisa toda hora, pare". Em geral aparece em integrações mal escritas que ficam em loop infinito consultando o status de uma nota a cada segundo até receber autorização.

A 656 atinge tanto consultas de protocolo quanto consultas de cadastro, status de serviço e DFe. O bloqueio é por tempo (geralmente alguns minutos a algumas horas), com penalidade crescente em caso de reincidência.

Causas mais comuns

• Polling agressivo após envio assíncrono: consultar consReciNFe a cada 1 segundo.
• Falta de backoff exponencial no integrador.
• Múltiplos servidores do mesmo CNPJ consultando em paralelo sem coordenação.
• Bug em loop infinito que consulta a mesma chave repetidamente.
• Não respeitar o tMed (tempo médio de processamento) retornado pela SEFAZ no envio do lote.

Regra de validação oficial

O MOC indica intervalos mínimos entre consultas:

• Consulta de recibo: respeitar tMed retornado na resposta do envio, geralmente 15 a 30 segundos.
• Consulta de protocolo: máximo de uma consulta por nota por minuto.
• Consulta de cadastro: limite por hora.
• Status de serviço: 3 minutos entre consultas.

Excedido o limite, a SEFAZ retorna 656 e bloqueia o emissor por janela de penalidade.

Exemplo XML, antes (errado)

Pseudocódigo de polling agressivo:

loop:
  resp = consultar_recibo(nRec)
  if resp.cStat == 105 (lote em processamento):
    continue (sem dormir)
  if resp.cStat == 104 (lote processado):
    break

Exemplo XML, depois (correto)

Polling correto com tMed:

resp = enviar_lote()
tEspera = resp.tMed  # tempo médio sugerido pela SEFAZ (em segundos)
sleep(tEspera)
 
for tentativa in 1..10:
  resp = consultar_recibo(nRec)
  if resp.cStat == 104:
    break
  sleep(min(tEspera * 2^tentativa, 60))  # backoff exponencial até 60s

Passo a passo para corrigir

1. Aguarde a janela de penalidade. Em geral, 5 a 30 minutos resolve. Não tente forçar nem reduzir intervalo.
2. Investigue o que disparou o excesso. Loop infinito? Múltiplos workers em paralelo?
3. Implemente backoff exponencial em todas as consultas. Comece em 15 segundos, dobre a cada tentativa, limite em 60 segundos.
4. Centralize as consultas em um único worker ou serviço, com fila e idempotência.
5. Respeite tMed na resposta do envio: ele é uma sugestão real da SEFAZ.
6. Reduza polling a um mínimo, prefira webhooks quando disponíveis (na NT 2022.003 algumas SEFAZ começaram a oferecer push).

Como o FazendaNota previne

O FazendaNota concentra as consultas de cada emitente, respeita o intervalo mínimo (tMed) informado pela SEFAZ e aumenta o tempo entre as tentativas a cada resposta de espera, em vez de consultar em loop. Resultados recentes são reaproveitados no lugar de repetir a mesma consulta, evitando o excesso de requisições que leva à rejeição 656.

Rejeições relacionadas

• Rejeição 217, NF-e não consta na base de dados da SEFAZ
• Rejeição 204, Duplicidade de NF-e
• Rejeição 215, Falha no Schema XML

Referência oficial

Esta rejeição está descrita no Anexo I - Leiaute e Regra de Validação do Manual de Orientação do Contribuinte (MOC) v7.0 da NF-e, publicado pelo CONFAZ. Texto integral em https://www.confaz.fazenda.gov.br/legislacao/arquivo-manuais/moc7-visao-geral.pdf