Responsável técnico (infRespTec)
O grupo infRespTec da NF-e (modelo 55) e da NFC-e (modelo 65) identifica, perante a SEFAZ, quem responde tecnicamente pelo sistema que emitiu o documento. Por padrão a plataforma declara os dados da NFE.io — o que atende a maioria dos clientes sem nenhuma configuração.
Se a sua empresa desenvolve o próprio sistema emissor e já está credenciada como fornecedora de sistema na UF, ela precisa figurar como responsável técnica das próprias notas. Este documento explica como cadastrar isso.
Só quem é fornecedor de sistema reconhecido no cadastro da SEFAZ do próprio estabelecimento. Se você emite pela NFE.io e não desenvolve o seu emissor, não precisa cadastrar nada — o comportamento padrão continua valendo.
Sumário
- Por que a SEFAZ valida este grupo
- Onde a UF entra na história
- Como a plataforma decide qual responsável técnico vai no XML
- Cadastrar na empresa
- Cadastrar as credenciais CSRT
- Cadastrar na subscription
- Coerência entre CNPJ e CSRT
- O que muda na emissão
- Como o segredo do CSRT é tratado
- Perguntas frequentes
Por que a SEFAZ valida este grupo
A SEFAZ não escolhe quem é o responsável técnico: ela compara o CNPJ declarado no infRespTec com o fornecedor de sistema reconhecido no cadastro daquele emitente. Quando os dois não batem, a nota é rejeitada:
Rejeição 974 — Informado grupo de Responsável Técnico com CNPJ divergente do cadastro na SEFAZ
Regra de validação da NT 2018.005.
Ou seja: um cliente que já está credenciado como fornecedor de sistema na UF não consegue emitir com o CNPJ da NFE.io no grupo. As duas saídas são:
| Saída | O que exige | Documentação |
|---|---|---|
| Apontar a NFE.io como fornecedora do seu estabelecimento | Ato administrativo no portal da SEFAZ | Habilitar o fornecedor no Paraná |
| Declarar a sua empresa como responsável técnica | Cadastro na NFE.io, descrito aqui | esta página |
Onde a UF entra na história
Duas exigências diferentes, que costumam ser confundidas:
| Exigência | UFs | O que significa |
|---|---|---|
Validar o CNPJ do infRespTec contra o cadastro | AM, MS, PE, PR, SC e TO (desde 2019) | O CNPJ declarado tem que ser o do fornecedor reconhecido, senão vem a rejeição 974 |
Exigir idCSRT e hashCSRT | Paraná, e somente na NF-e (modelo 55) | Além do CNPJ, o grupo leva um código de segurança do responsável técnico e um hash calculado nota a nota |
O CSRT (Código de Segurança do Responsável Técnico) é emitido pela Receita Estadual para o fornecedor de sistema. No Paraná ele é regido pela NPF 063/2012, itens 2.1 a 2.8: o fornecedor se credencia no UPD e recebe até 5 códigos, numerados de 1 a 5 (o idCSRT). O código em si é segredo; o que vai no XML é o hashCSRT, derivado do código somado à chave de acesso da nota — por isso ele é diferente em cada documento.
A credencial CSRT é emitida pela Receita Estadual por empresa e por UF, e só pode ser cadastrada na empresa — nunca na subscription. Como a plataforma nunca emite o CNPJ de uma camada com o hash de outra, o responsável técnico da subscription nunca é usado onde a UF exige CSRT: a resolução desce direto para o padrão da NFE.io.
Na prática, para emitir NF-e no Paraná com responsável técnico próprio, o cadastro tem que estar na empresa — responsável técnico e credencial CSRT, os dois. A camada da subscription atende as demais UFs, que validam o CNPJ mas não exigem CSRT.
Como a plataforma decide qual responsável técnico vai no XML
A resolução acontece nota a nota, em três camadas, na ordem:
| Camada | Onde cadastrar | Serve UF que exige CSRT? |
|---|---|---|
| 1 — Empresa | PUT /v3/companies/{company_id}/technicalresponsible + PUT /v3/companies/{company_id}/csrt | Sim — é a única que pode |
| 2 — Subscription | PUT /v3/Subscriptions({subscriptionId})/TechnicalResponsible | Não — não há onde guardar o CSRT |
| 3 — Padrão NFE.io | nada a cadastrar | Sim, mantido pela plataforma |
A camada 2 existe para quem opera várias empresas sob a mesma subscription: cadastre o responsável técnico uma vez e ele vale para todas as empresas que não tiverem um próprio.
O resultado já resolvido é guardado por 1 hora. A chave é empresa + UF + modelo do documento + ambiente, e o cache é por instância da plataforma — NF-e e NFC-e da mesma empresa, ou produção e homologação, são entradas independentes.
Depois de cadastrar, alterar ou remover, a mudança pode levar até uma hora para aparecer nas notas — inclusive quando o resultado é "usar o padrão da plataforma", que também é cacheado.
⚠️ Isso vale igualmente para rotacionar uma credencial CSRT: por até uma hora a emissão pode continuar derivando o hash do código anterior. Se você revogou um código junto à Receita Estadual, considere essa janela antes de emitir.
Falha de leitura do cadastro (indisponibilidade, timeout) nunca derruba a emissão: a resolução desce um degrau e a nota sai com a camada seguinte.
Cadastrar na empresa
Definir
PUT https://api.nfse.io/v3/companies/{company_id}/technicalresponsible
Authorization: <sua_api_key>
Content-Type: application/json
{
"technicalResponsible": {
"federalTaxNumber": "12345678000195",
"name": "Equipe de Integracoes",
"email": "[email protected]",
"phone": 1140638091
}
}
Resposta 200 com a empresa, já contendo o grupo technicalResponsible.
| Campo | Tipo | Regra |
|---|---|---|
federalTaxNumber | string | CNPJ do responsável técnico, com dígito verificador válido. Aceita CNPJ alfanumérico (IN RFB 2.229/2024). Aceito também como número JSON, mas prefira string — em CNPJ iniciado por zero o número perde o dígito |
name | string | Nome do contato técnico, 2 a 60 caracteres. Vai no xContato do XML |
email | string | E-mail do contato, até 60 caracteres |
phone | número | Só dígitos, 7 a 12 posições |
Erros de validação vêm em 400, um por campo:
| Código | Significado |
|---|---|
40047 | CNPJ do responsável técnico inválido |
40048 | Nome fora da faixa de 2 a 60 caracteres |
40049 | E-mail inválido |
40050 | Telefone fora da faixa de 7 a 12 dígitos |
Remover
DELETE https://api.nfse.io/v3/companies/{company_id}/technicalresponsible
Authorization: <sua_api_key>
Resposta 204. A empresa volta a resolver pela camada seguinte (subscription, depois padrão da plataforma).
Elas são segredo emitido pela Receita Estadual e reobtê-las custa trâmite administrativo. Sem responsável técnico cadastrado elas ficam inertes, porque não há CNPJ próprio a declarar — e voltam a valer se você cadastrar o responsável técnico novamente.
Cadastrar as credenciais CSRT
Necessário apenas para as UFs e modelos que exigem CSRT — hoje NF-e (modelo 55) no Paraná.
Incluir ou substituir
PUT https://api.nfse.io/v3/companies/{company_id}/csrt
Authorization: <sua_api_key>
Content-Type: application/json
{
"csrt": {
"state": "PR",
"idCSRT": 1,
"csrt": "{codigo-recebido-da-receita-estadual}"
}
}
Resposta 204 — a resposta nunca ecoa o código.
| Campo | Regra |
|---|---|
state | Sigla de uma das 27 unidades federativas. Não é "duas letras quaisquer" — a lista é fechada |
idCSRT | Inteiro de 1 a 5 (NPF 063/2012, itens 2.6 a 2.8) |
csrt | O código recebido da Receita Estadual. Obrigatório e não vazio |
A operação é um upsert por (UF, idCSRT): reenviar o mesmo par substitui o código. Como a faixa do idCSRT é 1 a 5, o teto de cinco credenciais por UF é estrutural — a sexta é recusada pela própria faixa.
| Código | Significado |
|---|---|
40019 | Empresa não está ativa |
40027 | state não é uma UF válida |
40051 | Credencial ausente no corpo |
40052 | idCSRT fora da faixa de 1 a 5 |
40053 | csrt nulo ou vazio |
Remover
DELETE https://api.nfse.io/v3/companies/{company_id}/csrt/{state}/{id_csrt}
Authorization: <sua_api_key>
Resposta 204.
Quando há mais de uma credencial cadastrada para a UF, a emissão usa a cadastrada por último, e só desempata pelo maior idCSRT. Com a faixa limitada a 1 a 5, rotacionar depois do quinto código é sobrescrever um slot — ordenar apenas pelo identificador daria a credencial errada nesse caso.
Cadastrar na subscription
Vale para todas as empresas da subscription que não tiverem responsável técnico próprio. Guarda só a identificação — nunca CSRT.
Consultar
GET https://api.nfse.io/v3/Subscriptions({subscriptionId})/TechnicalResponsible
Authorization: <sua_api_key>
| Resposta | Quando |
|---|---|
200 com o recurso | A subscription tem responsável técnico |
404 | A subscription não tem responsável técnico |
Nunca devolve 200 com corpo vazio: a ausência é sempre 404.
Definir
PUT https://api.nfse.io/v3/Subscriptions({subscriptionId})/TechnicalResponsible
Authorization: <sua_api_key>
Content-Type: application/json
{
"federalTaxNumber": "12345678000195",
"name": "Equipe de Integracoes",
"email": "[email protected]",
"phone": 1140638091
}
Resposta 200 com o recurso gravado. As regras de CNPJ, nome, e-mail e telefone são as mesmas do cadastro da empresa — a validação de domínio é compartilhada, para que um cadastro não aceite o que o outro recusa.
O formato do erro, porém, difere: nesta rota nome, e-mail e telefone são conferidos na borda, então um valor fora da faixa volta como 40001 com a descrição do campo, não como 40048/40049/40050. Só o 40047 (dígito verificador do CNPJ) chega da camada de domínio.
Remover
DELETE https://api.nfse.io/v3/Subscriptions({subscriptionId})/TechnicalResponsible
Authorization: <sua_api_key>
Resposta 204, idempotente — remover o que não existe também devolve 204.
Se o identificador da rota não for o da sua credencial, a resposta é 404 — nunca 403. Isso é deliberado: um 403 confirmaria a existência de um cadastro sob outra subscription. Identificador com formato inválido também devolve 404 nos três verbos.
Coerência entre CNPJ e CSRT
Numa UF que exige CSRT, declarar o CNPJ de uma camada com o hash derivado do CSRT de outra é rejeição 974 garantida. Por isso existe uma guarda: se a camada tem responsável técnico mas não tem credencial CSRT para aquela UF, a resolução desce um degrau em vez de misturar as origens.
Um exemplo concreto, NF-e no Paraná:
| Empresa | Subscription | Resultado |
|---|---|---|
| RT + CSRT do PR | — | Emite com o CNPJ e o CSRT da empresa |
| RT, sem CSRT do PR | RT | Desce para a subscription — que também não tem CSRT — e desce para o padrão da NFE.io |
| Sem RT | RT | Desce para o padrão da NFE.io, pelo mesmo motivo |
| Sem RT | Sem RT | Padrão da NFE.io, como sempre foi |
Numa UF que não exige CSRT, a identificação vale por si: a nota sai com o CNPJ da camada que respondeu, sem idCSRT e sem hashCSRT.
O que muda na emissão
Nada no seu payload. A resolução é automática, a partir do cadastro — não há campo novo na requisição de emissão de NF-e ou de NFC-e, nem cabeçalho a enviar.
O que muda é o XML autorizado:
<infRespTec>
<CNPJ>12345678000195</CNPJ>
<xContato>Equipe de Integracoes</xContato>
<email>[email protected]</email>
<fone>1140638091</fone>
<idCSRT>1</idCSRT>
<hashCSRT>...</hashCSRT>
</infRespTec>
Empresa sem responsável técnico cadastrado emite XML idêntico ao de antes desta mudança.
O hashCSRT é gravado junto com a nota. Reserializar ou baixar o XML de um documento já autorizado devolve o hash original, mesmo que a credencial CSRT tenha sido rotacionada depois.
Como o segredo do CSRT é tratado
O csrt é o único dado secreto deste cadastro, e é tratado como tal:
- Nunca devolvido em recurso público — nem no recurso da empresa, nem em resposta de escrita.
- Nunca gravado em cache distribuído nem no read model da empresa.
- Nunca gravado em log, inclusive no corpo de requisição registrado pela plataforma.
- Nunca presente nos eventos da nota fiscal — só o
idCSRT(que é o índice 1 a 5, não segredo) e o hash derivado, que já vai no XML autorizado.
O CNPJ, o nome, o e-mail e o telefone do responsável técnico não são segredo e aparecem normalmente no recurso da empresa e no da subscription.
O idCSRT não é segredo, mas também não é devolvido em recurso público — as credenciais CSRT ficam inteiras fora do recurso da empresa, para que acrescentar um campo homônimo no futuro não passe a expor o código por convenção de mapeamento. Consequência prática: não há como conferir por API quais credenciais estão cadastradas. Guarde o registro do que você cadastrou; para reconfirmar, reenvie o PUT do par (UF, idCSRT) — a operação é idempotente e sobrescreve o mesmo slot.
Perguntas frequentes
Preciso cadastrar algo se emito pela NFE.io e não desenvolvo meu emissor? Não. O padrão da plataforma continua valendo e nada muda.
Cadastrei o responsável técnico e a nota saiu com o CNPJ da NFE.io. Por quê? Quatro causas, na ordem de probabilidade: (1) o cache de 1 hora ainda não expirou; (2) a UF exige CSRT e a empresa não tem credencial cadastrada para ela, então a guarda de coerência desceu a cadeia; (3) o cadastro está só na subscription e a UF exige CSRT — essa camada nunca serve nesse caso; (4) o cadastro está na subscription, mas a empresa tem um responsável técnico próprio — a camada 1 ganha.
Recebi rejeição 974 mesmo com o responsável técnico cadastrado. O CNPJ cadastrado aqui tem que ser o do fornecedor de sistema reconhecido no cadastro da SEFAZ daquele estabelecimento. Cadastrar na NFE.io não credencia ninguém na SEFAZ — o credenciamento é ato administrativo, feito no portal da UF.
Posso cadastrar um responsável técnico por UF? Não. O cadastro do responsável técnico é um por empresa e um por subscription. O que é por UF são as credenciais CSRT.
Como confiro quais credenciais CSRT já cadastrei?
Não há endpoint público de leitura — as credenciais ficam fora do recurso da empresa por causa da custódia do segredo. Mantenha seu próprio registro; reenviar o PUT do par (UF, idCSRT) é idempotente e sobrescreve o mesmo slot.
A NFC-e no Paraná precisa de CSRT?
Hoje não. A exigência de idCSRT/hashCSRT vale para a NF-e modelo 55. Se a SEFAZ estender a exigência à NFC-e, a plataforma passa a atendê-la por configuração, sem mudança no seu lado.
Consulte também
- Habilitar o fornecedor e emissor de NF-e no Paraná — o caminho alternativo, apontando a NFE.io como fornecedora
- API de Empresas
- Conceitos sobre NF-e
- Credenciamento da NFC-e na SEFAZ