Como transmitir a DeRE

Em quatro passos, na ordem: gerar a credencial de API (client_id e client_secret) nos portais da Receita Federal; obter um token OAuth 2.0 no fluxo client_credentials; montar o lote de eventos, com cada evento assinado individualmente em XMLDSig; e enviar o XML do lote por POST em https://api.receitafederal.gov.br/dere/v1/recepcao/lotes, com os cabeçalhos Content-Type e Authorization. O processamento é assíncrono: a resposta traz um protocolo, e o resultado se consulta depois em GET https://api.receitafederal.gov.br/dere/v1/consulta/lotes/{protocolo}. A resposta HTTP 201 é só o protocolo provisório de entrega. A obrigação se cumpre com o Recibo de Processamento Definitivo que a consulta devolve.

Sim. O manual do desenvolvedor é explícito: a estrutura de lote é obrigatória para a transmissão de qualquer informação, e o endpoint de recepção espera receber o documento XML representativo do lote, não os arquivos de eventos soltos. O lote funciona como um envelope que agrupa os eventos já assinados, e ele próprio é validado contra o esquema XSD de lote antes de entrar na fila de processamento.

2. Cada token vale 60 minutos, e o manual do Receita Integra determina que se implemente cache para reutilizá-lo. ⚠ Isto decide arquitetura: quem pede token a cada requisição esgota o limite e passa a receber erro de autenticação em produção, no dia em que o volume subir. O token vai no cabeçalho Authorization: Bearer <access_token>.

Em produção, POST https://api.receitafederal.gov.br/dere/v1/recepcao/lotes para enviar o lote e GET https://api.receitafederal.gov.br/dere/v1/consulta/lotes/{protocolo} para consultar o processamento. Os endereços saíram no comunicado da Receita Federal e do CGIBS de 28/09/2026, com o tráfego aberto a partir de 01/10/2026 às 09h00 (horário de Brasília); antes disso o barramento rejeita a conexão. Na produção restrita, a URLBASE do manual é https://api.receitafederal.gov.br/prr-dere. O Authorization Server do token fica em https://api.receitafederal.gov.br/token, e a tabela de ambientes do manual da plataforma traz uma linha só, a de produção.

Com certificado ICP-Brasil, no padrão XML Digital Signature em formato Enveloped Signature, aplicado ao elemento que tem o atributo Id, com Reference URI apontando explicitamente para esse identificador. Padrão de assinatura: XML Digital Signature (XMLDSig); Formato da assinatura: Enveloped Signature; Certificado digital: ICP-Brasil; Cadeia de certificação: EndCertOnly; Tipo de certificado: A1 ou A3; Algoritmo de assinatura: RSA-SHA256; Codificação: Base64; Tamanho da chave: Compatível com certificados A1 e A3 (1024 e 2048 bits). ⚠ A cadeia é EndCertOnly: a assinatura deve conter apenas o certificado do assinante final, sem intermediários nem o da autoridade certificadora — incluir a cadeia inteira é o default de várias bibliotecas e reprova.

Possuir cadeia de certificação válida e confiável; Possuir cadeia certificadora vinculada à Autoridade Certificadora Raiz da ICPBrasil; Não estar revogado no momento da validação; Não estar expirado na data da verificação da assinatura; Ser do tipo e-CNPJ, e-PJ, e-CPF, e-PF ou e-Aplicação; Possuir os atributos digitalSignature e nonRepudiation definidos na extensão. As informações do certificado vão no elemento X509Certificate do XMLDSig.

O manual declara 5 dimensões de limite — Quantidade de requisições realizadas em determinado período; Frequência de consultas aos serviços; Quantidade de eventos por lote; Tamanho máximo das mensagens transmitidas; Tempo máximo de processamento das requisições. — e ⚠ **não publica os valores**: ele diz que os limites vigentes serão divulgados pelos canais oficiais (Portal SPED e Portal Nacional do IBS e da CBS). Ou seja, o teto existe e o número ainda não é público. O manual também nomeia os comportamentos a evitar: Consultas repetitivas em intervalos reduzidos; Retentativas contínuas sem controle; Transmissões redundantes do mesmo conteúdo; Processos automatizados que realizem chamadas em volume incompatível com a.

Depende do código, e o manual traz o tratamento recomendado de cada um: 200 OK — Processar normalmente a resposta retornada pela API. 202 Accepted — Armazenar o protocolo retornado e realizar consulta posterior do resultado do processamento. 400 Bad Request — Corrigir os dados da requisição antes de realizar novo envio. 401 Unauthorized — Obter novo token junto ao Receita Integra e repetir a operação. 403 Forbidden — Verificar credenciais, permissões e configurações de acesso. 404 Not Found — Verificar os parâmetros informados, como número de protocolo ou URL utilizada. ⚠ E há uma regra que antecede todas: em timeout ou falha de rede durante a transmissão de um lote, a aplicação não deve presumir que o lote não foi recebido; o certo é registrar a ocorrência e verificar antes de retransmitir, para não duplicar informação.

Existe a Produção Restrita, e ela não produz efeitos legais ou fiscais. ⚠ Ela se destina à validação funcional e técnica da integração: o manual diz que o ambiente não foi projetado para testes de carga, de estresse ou de desempenho, e que as aplicações não devem fazer transmissões massivas. Os dados são limpos periodicamente, e há API própria para isso: DELETE /v1/recepcao/limpezaDadosContribuinte/{cnpjDeclarante}.