---
title: "Responsável técnico (infRespTec) da NF-e e da NFC-e"
description: "Como cadastrar o responsável técnico do grupo infRespTec da NF-e e da NFC-e na empresa ou na subscription, incluindo as credenciais CSRT por UF, e como a plataforma resolve qual deles vai no XML."
source_url: https://nfe.io/docs/documentacao/gerenciamento-empresas/responsavel-tecnico
last_updated: 2026-09-04
---

# 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.

:::info[Quem precisa ler]
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](#por-que-a-sefaz-valida-este-grupo)
- [Onde a UF entra na história](#onde-a-uf-entra-na-história)
- [Como a plataforma decide qual responsável técnico vai no XML](#como-a-plataforma-decide-qual-responsável-técnico-vai-no-xml)
- [Cadastrar na empresa](#cadastrar-na-empresa)
- [Cadastrar as credenciais CSRT](#cadastrar-as-credenciais-csrt)
- [Cadastrar na subscription](#cadastrar-na-subscription)
- [Coerência entre CNPJ e CSRT](#coerência-entre-cnpj-e-csrt)
- [O que muda na emissão](#o-que-muda-na-emissão)
- [Como o segredo do CSRT é tratado](#como-o-segredo-do-csrt-é-tratado)
- [Perguntas frequentes](#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](https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=04BIflQt1aY=).

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á](../nota-fiscal-produto-eletronica/como-habilitar-o-fornecedor-e-emissor-de-nota-fiscal-nfe-mercadoria-estado-do-parana.md) |
| 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.

:::danger[Numa UF que exige CSRT, a camada da subscription não serve]
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:

```mermaid
flowchart TD
    A[Emissão de NF-e ou NFC-e] --> B{Empresa tem<br/>responsável técnico?}
    B -- sim --> C[Usa o da empresa]
    B -- não --> D{Subscription tem<br/>responsável técnico?}
    D -- sim --> E[Usa o da subscription]
    D -- não --> F[Usa o padrão da NFE.io]
```

| 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.

:::note[Cache de 1 hora — vale também para rotação de CSRT]
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

```http
PUT https://api.nfse.io/v3/companies/{company_id}/technicalresponsible
Authorization: <sua_api_key>
Content-Type: application/json
```

```json
{
  "technicalResponsible": {
    "federalTaxNumber": "12345678000195",
    "name": "Equipe de Integracoes",
    "email": "integracoes@suaempresa.com.br",
    "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

```http
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).

:::info[Remover o responsável técnico não apaga as credenciais CSRT]
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

```http
PUT https://api.nfse.io/v3/companies/{company_id}/csrt
Authorization: <sua_api_key>
Content-Type: application/json
```

```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

```http
DELETE https://api.nfse.io/v3/companies/{company_id}/csrt/{state}/{id_csrt}
Authorization: <sua_api_key>
```

Resposta `204`.

:::note[Qual credencial a emissão usa]
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

```http
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

```http
PUT https://api.nfse.io/v3/Subscriptions({subscriptionId})/TechnicalResponsible
Authorization: <sua_api_key>
Content-Type: application/json
```

```json
{
  "federalTaxNumber": "12345678000195",
  "name": "Equipe de Integracoes",
  "email": "integracoes@suaempresa.com.br",
  "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

```http
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`.

:::warning[A subscription da rota tem que ser a sua]
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:

```xml
<infRespTec>
  
  <xContato>Equipe de Integracoes</xContato>
  <email>integracoes@suaempresa.com.br</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.

:::note[Reserializar uma nota já emitida]
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á](../nota-fiscal-produto-eletronica/como-habilitar-o-fornecedor-e-emissor-de-nota-fiscal-nfe-mercadoria-estado-do-parana.md) — o caminho alternativo, apontando a NFE.io como fornecedora
- [API de Empresas](./gerenciamento-empresas.md)
- [Conceitos sobre NF-e](../nota-fiscal-produto-eletronica/conceitos.md)
- [Credenciamento da NFC-e na SEFAZ](../nota-fiscal-consumidor/credenciamento.md)