Documentação API NFS-e
Guia completo para integração com o sistema de Nota Fiscal de Serviços Eletrônica da Centi
Começando
A API NFS-e da Centi permite que empresas emitam notas fiscais de serviço diretamente de seus sistemas próprios através de integração via API REST.
Pré-requisitos
- Credenciais de acesso: Usuário e senha fornecidos pela prefeitura municipal
- Certificado Digital: Certificado A1 ou A3 válido para assinatura dos XMLs
- Cadastro ativo: Empresa cadastrada e habilitada no sistema da prefeitura
- Conhecimento técnico: Familiaridade com APIs REST e formato XML
Quick Start - 3 Passos
Entre em contato com a prefeitura do município para obter seu usuário e senha de acesso à API. É a mesma senha de acesso ao portal para emissão manual.
Monte o XML da NFS-e conforme o schema XSD fornecido. Assine digitalmente o XML com seu certificado digital.
Faça uma requisição POST para o endpoint da API com suas credenciais e o XML no corpo da requisição.
Autenticação
A API NFS-e utiliza autenticação via HTTP Basic Auth. Você deve incluir suas
credenciais (usuário e senha) codificadas em Base64 no header Authorization.
Formato do Header
Authorization: Basic {base64(usuario:senha)}
Exemplo
Credenciais:
Usuário: "empresa123"
Senha: "senhaSegura@2025"
Codificação Base64:
echo -n "empresa123:senhaSegura@2025" | base64
# Resultado: ZW1wcmVzYTEyMzpzZW5oYVNlZ3VyYUAyMDI1
Header Final:
Authorization: Basic ZW1wcmVzYTEyMzpzZW5oYVNlZ3VyYUAyMDI1
Estrutura da API
URL Base
https://api.centi.com.br
Por padrão, todas as requisições precisam informar a sigla UF do prestador do serviço e o
identificador do prestador (nome da cidade) representado pela variável Tenant.
Formato das URLs
https://api.centi.com.br/{recurso}/{UF}/{Tenant}
Exemplo:
https://api.centi.com.br/nfe/gerar/go/rioverde
| Parâmetro | Descrição | Exemplo |
|---|---|---|
{UF} |
Sigla da UF em minúsculo | go, sp, rj |
{Tenant} |
Nome do município | rioverde, goiania |
Emitir Nota Fiscal
Endpoint
POST https://api.centi.com.br/nfe/gerar/{UF}/{Tenant}
Request Completo
POST https://api.centi.com.br/nfe/gerar/go/rioverde
Headers:
Content-Type: application/xml; charset=utf-8
Authorization: Basic {suas_credenciais_base64}
Body:
<GerarNfseEnvio xmlns="http://www.centi.com.br/files/nfse.xsd">
<!-- XML da NFS-e -->
</GerarNfseEnvio>
Classificação do Serviço: NBS, INDOP e Classificação Tributária
No XML de emissão, as tags <CodigoNbs>, <CodigoINDOP> e
<CodigoClassTrib> devem ser enviadas dentro do grupo <Servico>,
respeitando a sequência abaixo:
<Servico>
<Valores>
<!-- valores do serviço -->
</Valores>
<IssRetido>2</IssRetido>
<ItemListaServico>01.07</ItemListaServico>
<CodigoNbs>1.2345.67.89</CodigoNbs>
<CodigoINDOP>010101</CodigoINDOP>
<CodigoClassTrib>000001</CodigoClassTrib>
<CodigoCnae>6201501</CodigoCnae>
<!-- demais campos do serviço -->
</Servico>
Obrigatoriedade por regra de negócio
No XSD, <CodigoINDOP> e <CodigoClassTrib> possuem
minOccurs="0" para compatibilidade estrutural. Entretanto, no fluxo de emissão,
o provider aplica as validações de negócio e poderá rejeitar o lote quando as informações
estiverem ausentes, inválidas ou incompatíveis com o NBS informado.
Retenções Federais e Detalhamento PIS/COFINS (NT 007)
O grupo <Valores> passou a aceitar sete novas tags de detalhamento
federal. Elas são opcionais no XSD, mas devem respeitar obrigatoriamente a sequência
abaixo, sempre após <DescontoCondicionado>:
<Valores>
<ValorServicos>1000.00</ValorServicos>
<ValorDeducoes>0.00</ValorDeducoes>
<ValorPis>0.00</ValorPis>
<ValorCofins>0.00</ValorCofins>
<ValorInss>0.00</ValorInss>
<ValorIr>0.00</ValorIr>
<ValorCsll>0.00</ValorCsll>
<OutrasRetencoes>0.00</OutrasRetencoes>
<ValorIss>50.00</ValorIss>
<Aliquota>5</Aliquota>
<DescontoIncondicionado>0.00</DescontoIncondicionado>
<DescontoCondicionado>0.00</DescontoCondicionado>
<!-- Detalhamento Federal (NT 007) -->
<CstPisCofins>01</CstPisCofins>
<TpRetPisCofins>1</TpRetPisCofins>
<VlBcPisCofins>0.00</VlBcPisCofins>
<PAliqPis>0.00</PAliqPis>
<PAliqCofins>0.00</PAliqCofins>
<VlRetCSLL>0.00</VlRetCSLL>
<VlINSS>0.00</VlINSS>
</Valores>
| Tag | Tipo | Descrição |
|---|---|---|
CstPisCofins | Texto | Código de Situação Tributária de PIS/COFINS, conforme tabela da NT 007 |
TpRetPisCofins | Numérico | Tipo de retenção de PIS/COFINS, conforme tabela da NT 007 |
VlBcPisCofins | Decimal | Valor da base de cálculo de PIS/COFINS |
PAliqPis | Decimal | Alíquota de PIS aplicada (percentual) |
PAliqCofins | Decimal | Alíquota de COFINS aplicada (percentual) |
VlRetCSLL | Decimal | Valor de CSLL retido |
VlINSS | Decimal | Contribuição Previdenciária retida |
<Aliquota> passou a ser obrigatória no XSD
No schema atual, <Aliquota> deixou de ser opcional
(minOccurs="0") e passou a minOccurs="1" dentro de
<Valores>. XMLs sem essa tag falham na validação estrutural.
Blocos opcionais: CondicaoPagamento, DadosObra e DadosImovel
Estes três grupos ficam no final de
<InfDeclaracaoPrestacaoServico>, após
<IncentivoFiscal> e nesta ordem:
<RegimeEspecialTributacao>1</RegimeEspecialTributacao>
<OptanteSimplesNacional>2</OptanteSimplesNacional>
<IncentivoFiscal>2</IncentivoFiscal>
<!-- Condições de pagamento -->
<CondicaoPagamento>
<Condicao>1</Condicao>
<QuantidadeParcela>3</QuantidadeParcela>
<Observacao>Pagamento em 3 parcelas mensais</Observacao>
<Parcela>
<Parcela>1</Parcela>
<Valor>333.34</Valor>
</Parcela>
</CondicaoPagamento>
<!-- Dados da obra (construção civil) -->
<DadosObra>
<CnoObra>123456789012</CnoObra>
<CepObra>74000000</CepObra>
<LogradouroObra>AVENIDA ANHANGUERA</LogradouroObra>
<NumeroObra>123</NumeroObra>
<BairroObra>CENTRO</BairroObra>
<ComplementoObra>QUADRA 5</ComplementoObra>
<QuadraObra>5</QuadraObra>
<LoteObra>12</LoteObra>
</DadosObra>
<!-- Dados do imóvel -->
<DadosImovel>
<CibImovel>987654321</CibImovel>
<CepImovel>74000000</CepImovel>
<LogradouroImovel>AVENIDA ANHANGUERA</LogradouroImovel>
<NumeroImovel>123</NumeroImovel>
<BairroImovel>CENTRO</BairroImovel>
</DadosImovel>
</InfDeclaracaoPrestacaoServico>
Onde enviar o <DadosObra>
O XSD permite <DadosObra> tanto dentro de
<Prestador> quanto diretamente em
<InfDeclaracaoPrestacaoServico>. Utilize apenas a segunda
forma (nível de InfDeclaracaoPrestacaoServico), que é o local
oficialmente documentado e suportado. As tags usam PascalCase:
<CnoObra>, <CepObra>,
<LogradouroObra>, <NumeroObra>,
<BairroObra>, <ComplementoObra>,
<QuadraObra> e <LoteObra>.
Os nomes com sufixo Fild (<cepObraFild> etc.) permanecem
no schema apenas por retrocompatibilidade e não devem ser usados em novas integrações.
Retenções e Detalhamento Federal (NT 007)
O grupo <Valores> passou a aceitar sete novos campos de detalhamento
federal. Eles são opcionais no XSD, porém devem obrigatoriamente ser enviados
após <DescontoCondicionado>, respeitando a sequência abaixo:
<Valores>
<ValorServicos>1000.00</ValorServicos>
<ValorDeducoes>0.00</ValorDeducoes>
<ValorPis>0.00</ValorPis>
<ValorCofins>0.00</ValorCofins>
<ValorInss>0.00</ValorInss>
<ValorIr>0.00</ValorIr>
<ValorCsll>0.00</ValorCsll>
<OutrasRetencoes>0.00</OutrasRetencoes>
<ValorIss>50.00</ValorIss>
<Aliquota>5</Aliquota>
<DescontoIncondicionado>0.00</DescontoIncondicionado>
<DescontoCondicionado>0.00</DescontoCondicionado>
<!-- Detalhamento Federal (NT 007) -->
<CstPisCofins>01</CstPisCofins>
<TpRetPisCofins>1</TpRetPisCofins>
<VlBcPisCofins>1000.00</VlBcPisCofins>
<PAliqPis>0.65</PAliqPis>
<PAliqCofins>3.00</PAliqCofins>
<VlRetCSLL>0.00</VlRetCSLL>
<VlINSS>0.00</VlINSS>
</Valores>
| Tag | Tipo | Descrição |
|---|---|---|
CstPisCofins |
Texto | Código de Situação Tributária de PIS/COFINS, conforme tabela da NT 007 |
TpRetPisCofins |
Numérico | Tipo de retenção de PIS/COFINS, conforme tabela da NT 007 |
VlBcPisCofins |
Decimal | Valor da base de cálculo de PIS/COFINS |
PAliqPis |
Decimal | Alíquota de PIS (%) |
PAliqCofins |
Decimal | Alíquota de COFINS (%) |
VlRetCSLL |
Decimal | Valor retido de CSLL |
VlINSS |
Decimal | Contribuição Previdenciária Retida |
<Aliquota> passou a ser obrigatória no XSD
No schema anterior <Aliquota> era minOccurs="0".
No schema atual ela é minOccurs="1" dentro de <Valores>.
A ausência da tag quebra a validação estrutural do XML.
Valores de domínio
Os códigos válidos de <CstPisCofins> e <TpRetPisCofins>
seguem as tabelas oficiais da NT 007 do padrão nacional da NFS-e.
Consulte a NT vigente para a relação completa dos códigos.
Blocos opcionais: CondicaoPagamento, DadosObra e DadosImovel
Três blocos opcionais foram disponibilizados no final de
<InfDeclaracaoPrestacaoServico>, obrigatoriamente
após <IncentivoFiscal> e nesta ordem:
<RegimeEspecialTributacao>1</RegimeEspecialTributacao>
<OptanteSimplesNacional>2</OptanteSimplesNacional>
<IncentivoFiscal>2</IncentivoFiscal>
<!-- 1. Condições de pagamento -->
<CondicaoPagamento>
<Condicao>1</Condicao>
<QuantidadeParcela>3</QuantidadeParcela>
<Observacao>Pagamento em 3 parcelas mensais</Observacao>
<Parcela>
<Parcela>1</Parcela>
<Valor>333.34</Valor>
</Parcela>
<Parcela>
<Parcela>2</Parcela>
<Valor>333.33</Valor>
</Parcela>
</CondicaoPagamento>
<!-- 2. Dados da obra (construção civil) -->
<DadosObra>
<CnoObra>123456789012</CnoObra>
<CepObra>74000000</CepObra>
<LogradouroObra>AVENIDA ANHANGUERA</LogradouroObra>
<NumeroObra>123</NumeroObra>
<BairroObra>CENTRO</BairroObra>
<ComplementoObra>QUADRA 10</ComplementoObra>
<QuadraObra>10</QuadraObra>
<LoteObra>5</LoteObra>
</DadosObra>
<!-- 3. Dados do imóvel -->
<DadosImovel>
<CibImovel>987654321</CibImovel>
<CepImovel>74000000</CepImovel>
<LogradouroImovel>AVENIDA ANHANGUERA</LogradouroImovel>
<NumeroImovel>123</NumeroImovel>
<BairroImovel>CENTRO</BairroImovel>
</DadosImovel>
</InfDeclaracaoPrestacaoServico>
Posicionamento e capitalização do <DadosObra>
Envie <DadosObra> diretamente em
<InfDeclaracaoPrestacaoServico>, após <IncentivoFiscal>
e antes de <DadosImovel>. Todas as tags usam PascalCase — atenção
especial ao <CnoObra> (e não <Cno>). Os nomes com sufixo
Fild (<cepObraFild>, <logradouroObraFild> etc.)
permanecem no schema apenas por retrocompatibilidade e não devem ser usados em novas
integrações.
Validações realizadas pelo sistema
- NBS x Serviço: o
<CodigoNbs>deve estar associado ao serviço informado em<ItemListaServico>, conforme o cadastro AR017. - INDOP x NBS: o
<CodigoINDOP>deve possuir exatamente 6 dígitos numéricos, sem pontos, e corresponder ao INDOP vinculado ao NBS. - Classificação Tributária x NBS: o
<CodigoClassTrib>deve possuir exatamente 6 dígitos numéricos e corresponder à classificação vinculada ao NBS. - Persistência: após a validação, o identificador interno do NBS é gravado na nota fiscal gerada.
Exemplos de rejeição
Código NBS inválido para o serviço informado.Código INDOP inválido para o NBS informado.Classificação Tributária inválida para o NBS informado.
Response de Sucesso (HTTP 200)
Quando a nota é emitida com sucesso, a API retorna um XML contendo:
- Número da NFS-e gerada
- Código de verificação
- Data e hora da emissão
- XML completo da nota autorizada
- Bloco
<DadosNotaNacional>com os dados da Reforma Tributária
O grupo <InfNfse> do retorno passou a incluir os campos
<DescricaoCancelamento>, <DescricaoSubstituicao>,
<Discriminacao>, <Observacao> e o bloco
<DadosNotaNacional>:
<DadosNotaNacional>
<AliqotaIBS>0</AliqotaIBS>
<AliquotaCBS>0</AliquotaCBS>
<ValorIBS>0</ValorIBS>
<ValorCBS>0</ValorCBS>
<ChaveAcessoNacional>...</ChaveAcessoNacional>
</DadosNotaNacional>
Atenção à grafia de <AliqotaIBS>
A tag é declarada no XSD como <AliqotaIBS> (sem a letra "u"),
diferente de <AliquotaCBS>. Ao fazer o parse do retorno, utilize
exatamente a grafia do schema. Além disso, no grupo <ValoresNfse>
os campos BaseCalculo, Aliquota, ValorIss e
ValorLiquidoNfse passaram a ser sempre retornados
(minOccurs="1").
Erros Comuns
| Código | Erro | Solução |
|---|---|---|
401 |
Credenciais inválidas | Verifique usuário e senha |
400 |
XML mal formatado | Valide o XML contra o XSD |
422 |
Dados inválidos ou vínculo fiscal inconsistente | Verifique CNPJ/CPF, NBS, INDOP, Classificação Tributária e o vínculo com o serviço |
500 |
Erro no servidor | Tente novamente ou contate suporte |
Cancelar Nota Fiscal
Endpoint
POST https://api.centi.com.br/nfe/cancelar/{UF}/{Tenant}
Estrutura do XML de Cancelamento
<CancelarNfseEnvio xmlns="http://www.centi.com.br/files/nfse.xsd">
<Pedido>
<InfPedidoCancelamento>
<IdentificacaoNfse>
<Numero>123456</Numero>
<CpfCnpj>
<Cnpj>12345678000195</Cnpj>
</CpfCnpj>
<InscricaoMunicipal>12345</InscricaoMunicipal>
<CodigoMunicipio>5218805</CodigoMunicipio>
<CodigoVerificacao>ABCD1234</CodigoVerificacao>
<DescricaoCancelamento>Motivo do cancelamento</DescricaoCancelamento>
<Id>nfse_guid_123456789012345678901234567890</Id>
</IdentificacaoNfse>
<CodigoCancelamento>1</CodigoCancelamento>
</InfPedidoCancelamento>
<Signature><!-- Assinatura Digital --></Signature>
</Pedido>
</CancelarNfseEnvio>
Campos que passaram a ser obrigatórios
Em <IdentificacaoNfse>, as tags
<CodigoVerificacao> e <Id> passaram a
minOccurs="1". A tag <CodigoCancelamento> também
deixou de ser opcional em <InfPedidoCancelamento>.
A ordem exigida é: Numero, CpfCnpj,
InscricaoMunicipal, CodigoMunicipio,
CodigoVerificacao, DescricaoCancelamento, Id.
Código de Cancelamento
| Código | Descrição |
|---|---|
1 |
Rasura |
2 |
Erro preenchimento |
3 |
Fim do prazo de validade |
4 |
Fora de sequência numérica e cronológica |
5 |
Desacordo comercial |
6 |
Outros |
Substituir Nota Fiscal
Endpoint
POST https://api.centi.com.br/nfe/gerar/{UF}/{Tenant}
A substituição utiliza o mesmo endpoint de geração, mas com informações adicionais sobre qual nota está sendo substituída.
Bloco RpsSubstituido
<Rps>
<IdentificacaoRps>
<Numero>2</Numero>
<Serie>A1</Serie>
<Tipo>1</Tipo>
</IdentificacaoRps>
<DataEmissao>2025-12-16</DataEmissao>
<Status>1</Status>
<!-- Bloco de Substituição -->
<RpsSubstituido>
<Numero>1</Numero>
<Serie>A1</Serie>
<Tipo>1</Tipo>
</RpsSubstituido>
</Rps>
Como funciona:
Ao enviar um XML com o bloco <RpsSubstituido>,
o sistema cancela automaticamente a nota anterior e gera uma nova nota com os dados atualizados.
Principais Campos do XML
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
Numero |
Numérico | SIM | Número do RPS |
Serie |
Texto | SIM | Série do RPS |
DataEmissao |
Data | SIM | Data emissão (YYYY-MM-DD) |
ValorServicos |
Decimal | SIM | Valor total dos serviços |
ValorIss |
Decimal | SIM | Valor do ISS |
Aliquota |
Decimal | SIM | Alíquota do ISS (%) |
ItemListaServico |
Texto | SIM | Código serviço LC 116/2003 |
CodigoNbs |
Texto | REGRA DE NEGÓCIO | Código NBS vinculado ao serviço cadastrado na AR017 |
CodigoINDOP |
Numérico (6 dígitos) | REGRA DE NEGÓCIO | Indicador da operação, sem pontos, vinculado ao NBS informado; minOccurs="0" no XSD |
CodigoClassTrib |
Numérico (6 dígitos) | REGRA DE NEGÓCIO | Classificação Tributária vinculada ao NBS informado; minOccurs="0" no XSD |
CodigoCnae |
Numérico | SIM | Código CNAE |
Discriminacao |
Texto | SIM | Descrição do serviço |
IssRetido |
Numérico | SIM | 1=Sim, 2=Não |
CstPisCofins |
Texto | NÃO | CST de PIS/COFINS (NT 007) — dentro de <Valores> |
TpRetPisCofins |
Numérico | NÃO | Tipo de retenção de PIS/COFINS (NT 007) |
VlBcPisCofins |
Decimal | NÃO | Base de cálculo de PIS/COFINS |
PAliqPis / PAliqCofins |
Decimal | NÃO | Alíquotas de PIS e COFINS aplicadas |
VlRetCSLL |
Decimal | NÃO | Valor de CSLL retido |
VlINSS |
Decimal | NÃO | Contribuição Previdenciária retida |
Condicao |
Numérico | NÃO | Condição de pagamento; obrigatório se <CondicaoPagamento> for enviado |
QuantidadeParcela |
Numérico | NÃO | Quantidade de parcelas; obrigatório dentro de <CondicaoPagamento> |
CnoObra |
Texto | NÃO | CNO da obra, em <DadosObra> (PascalCase) |
CibImovel |
Texto | NÃO | Código CIB do imóvel, em <DadosImovel> |
Códigos de Referência
ISS Retido
| Código | Significado |
|---|---|
1 |
Sim - ISS retido pelo tomador |
2 |
Não - ISS recolhido pelo prestador |
Códigos de Serviço (Principais)
| Código | Descrição |
|---|---|
01.07 |
Desenvolvimento de programas |
04.01 |
Medicina e biomedicina |
07.01 |
Engenharia, arquitetura |
16.02 |
Transporte municipal |
17.01 |
Assessoria ou consultoria |
Detalhamento Federal (NT 007)
| Campo | Formato | Origem do domínio |
|---|---|---|
CstPisCofins |
Texto (código numérico com zeros à esquerda, ex.: 01) |
Tabela de CST de PIS/COFINS da NT 007 |
TpRetPisCofins |
Numérico inteiro | Tabela de tipos de retenção de PIS/COFINS da NT 007 |
Condicao |
Numérico inteiro (até 5 dígitos) | Condição de pagamento, conforme domínio da NT 007 |
Referência oficial
Os valores válidos desses campos não são fixados no XSD da Centi: seguem as tabelas publicadas na Nota Técnica 007 do padrão nacional da NFS-e. Consulte sempre a versão vigente da NT para a relação completa e atualizada dos códigos.
NBS, INDOP e Classificação Tributária
| Campo | Formato | Validação aplicada |
|---|---|---|
CodigoNbs |
Código textual conforme cadastro NBS | Deve existir e estar vinculado ao ItemListaServico informado |
CodigoINDOP |
6 dígitos numéricos, sem pontuação | Deve coincidir exatamente com o INDOP cadastrado para o NBS |
CodigoClassTrib |
6 dígitos numéricos | Deve coincidir exatamente com a Classificação Tributária cadastrada para o NBS |
Validação estrutural x validação de negócio
O XSD verifica presença opcional, sequência e formato. A compatibilidade entre Serviço, NBS, INDOP e Classificação Tributária é validada no processamento da API com base nos cadastros da Centi.
Perguntas Frequentes
Como obter as credenciais de acesso?
Entre em contato com a prefeitura do município onde sua empresa está cadastrada.
Preciso de certificado digital?
Sim. O XML deve ser assinado digitalmente com certificado A1 ou A3 válido.
Posso cancelar uma nota via API?
Sim, através do endpoint POST /nfe/cancelar/{UF}/{Tenant} com XML de cancelamento.
Posso substituir uma nota já emitida?
Sim. Use o endpoint de geração mas adicione o bloco <RpsSubstituido>
informando a nota que está sendo substituída.
Por que CodigoINDOP e CodigoClassTrib são opcionais no XSD, mas podem gerar rejeição?
O atributo minOccurs="0" mantém compatibilidade estrutural do schema. Na emissão, porém, o provider aplica regras de negócio e valida os códigos contra o cadastro do NBS. Assim, um XML pode passar na validação XSD e ainda ser rejeitado por inconsistência cadastral.
Documentação OpenAPI / Swagger
Tenha acesso a documentação interativa no padrão OpenAPI.
Especificação OpenAPI
Arquivos para Download
Baixe os exemplos completos de XML:
Atualizações/Alterações
O schema oficial da Centi foi atualizado, ampliando o XML de emissão com campos de detalhamento federal, blocos de condição de pagamento, obra e imóvel, além de endurecer a obrigatoriedade de alguns campos já existentes.
<CstPisCofins>,<TpRetPisCofins>,<VlBcPisCofins>,<PAliqPis>,<PAliqCofins>,<VlRetCSLL>e<VlINSS>.- Devem ser enviados no final do grupo
<Valores>, após<DescontoCondicionado>, na ordem definida no XSD. - Os domínios de
CstPisCofinseTpRetPisCofinsseguem as tabelas da NT 007.
<CondicaoPagamento>—Condicao,QuantidadeParcela,Observacaoe uma ou mais<Parcela>.<DadosObra>—CnoObra,CepObra,LogradouroObra,NumeroObra,BairroObra,ComplementoObra,QuadraObra,LoteObra.<DadosImovel>—CibImovel,CepImovel,LogradouroImovel,NumeroImovel,BairroImovel.- Os três blocos vão após
<IncentivoFiscal>, nesta ordem.
<Aliquota>dentro de<Valores>.<Signature>na declaração de prestação de serviço e no pedido de cancelamento.<CodigoVerificacao>e<Id>em<IdentificacaoNfse>, e<CodigoCancelamento>em<InfPedidoCancelamento>.
<CodigoNbs>é aceito com ou sem pontos separadores.- Nomenclatura de obra: use
<CnoObra>(PascalCase). As tags legadas com sufixoFildcontinuam aceitas por retrocompatibilidade, mas são desaconselhadas. - O bloco
<Prestador>passou a aceitarEndereco,Contato,RazaoSocial,NomeFantasiaeInscricaoEstadual. <Tomador>passou a aceitarEstrangeiro,DocumentoEstrangeiroeInscricaoEstadual.- No retorno,
<InfNfse>incluiDescricaoCancelamento,DescricaoSubstituicao,Discriminacao,Observacaoe<DadosNotaNacional>. - O validador da documentação recebeu 5 novas regras e teve as regras de
<DadosObra>revisadas.
O XML de emissão passa a receber as tags <CodigoINDOP> e <CodigoClassTrib> dentro do grupo <Servico>, logo após <CodigoNbs>. Os dados são utilizados para validar a classificação da operação e garantir a persistência do NBS correto na NFS-e.
<ItemListaServico>01.07</ItemListaServico>
<CodigoNbs>1.2345.67.89</CodigoNbs>
<CodigoINDOP>010101</CodigoINDOP>
<CodigoClassTrib>000001</CodigoClassTrib>
<CodigoCnae>6201501</CodigoCnae>
Regras aplicadas no processamento:
- O NBS deve estar vinculado ao serviço informado em
<ItemListaServico>, conforme cadastro AR017. - O INDOP deve conter 6 dígitos numéricos, sem pontos, e coincidir com o código vinculado ao NBS.
- A Classificação Tributária deve conter 6 dígitos numéricos e coincidir com o cadastro do NBS.
- Em caso de divergência, o lote de RPS é rejeitado com mensagem específica ao contribuinte.
- No XSD, as duas novas tags permanecem com
minOccurs="0"; a obrigatoriedade é tratada como regra de negócio no provider.
Código INDOP inválido para o NBS informado.Classificação Tributária inválida para o NBS informado.Código NBS inválido para o serviço informado.
A documentação da API agora conta com um Validador de XML integrado. Antes de enviar seu XML à API, você pode verificar instantaneamente se a estrutura está correta — sem precisar abrir chamado de suporte.
- Namespace correto (
http://www.centi.com.br/files/nfse.xsd) - Encoding e estrutura XML (parse errors)
- Tamanho fixo de CPF (11 dígitos), CNPJ (14 dígitos), CEP (8 dígitos) e UF (2 caracteres)
- Campo
<CodigoNbs>obrigatório por regra de negócio - Campos
<CodigoINDOP>e<CodigoClassTrib>com exatamente 6 dígitos numéricos - Sequência correta das tags no grupo
<Servico>: NBS → INDOP → Classificação Tributária - Datas no formato ISO 8601 (
dateTime) - Valores decimais com ponto (não vírgula) como separador
- Campos obsoletos:
<NaturezaOperacao>,<NomeFantasia>no Tomador,<Observacao>no nível principal - Validações de padrão XSD:
IssRetido,Status,ExigibilidadeISS,CodigoCancelamentoe outros
- Acesse o menu Validador de XML na barra lateral
- Arraste o arquivo
.xmlou cole o conteúdo diretamente - Clique em Validar XML — o resultado aparece imediatamente
A partir de 13/01/2026, os XMLs de envio e retorno passam a incluir o campo <CodigoNbs> (Nomenclatura Brasileira de Serviços) dentro do grupo <Servico>, efetuando assim a classificação do serviço conforme a NBS.
- Tag:
<CodigoNbs>- Código da Nomenclatura Brasileira de Serviços (NBS) - Localização no XML de envio:
<Servico>dentro de<InfDeclaracaoPrestacaoServico> - Localização no XML de retorno:
<Servico>dentro de<DeclaracaoPrestacaoServico> - Formato no layout Centi atual: 12 caracteres conforme
tsCodigoNbsdo XSD (ex.:1.2345.67.89) - Obrigatoriedade: Campo obrigatório para todas as notas fiscais emitidas
- Relação com ItemListaServico: O código NBS deve ser compatível com o Item da Lista de Serviços (LC 116/2003) informado
- A tabela completa de códigos NBS está disponível no link "https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc/anexoviii-correlacaoitemnbsindopcclasstrib_ibscbs_v1-00-00.xlsx"
- O código NBS deve ser selecionado conforme a atividade específica do serviço prestado
- A relação entre ItemListaServico (LC 116/2003) e CodigoNbs é de 1 para N (um item da lista pode ter vários códigos NBS)
- Sistemas integradores devem implementar validação do código NBS para evitar rejeição
O XML de envio agora suporta informações sobre RPS que está sendo substituído através da nova tag <RpsSubstituido> dentro do grupo <Rps>.
- Tag principal:
<RpsSubstituido>- Contém dados do RPS que está sendo substituído <Numero>- Número do RPS substituído<Serie>- Série do RPS substituído<Tipo>- Tipo do RPS substituído
O XML de envio agora permite informar dados detalhados da obra diretamente no grupo <Prestador> através da nova tag <DadosObra>.
- Tag principal:
<DadosObra>- Contém informações detalhadas da obra <Cno>- Código CNO (Cadastro Nacional de Obras) da obra<CepObra>- CEP do local da obra<LogradouroObra>- Logradouro completo da obra<NumeroObra>- Número do endereço da obra<BairroObra>- Bairro onde está localizada a obra<ComplementoObra>- Complemento do endereço da obra<QuadraObra>- Quadra da obra (quando aplicável)<LoteObra>- Lote da obra (quando aplicável)
Atenção: todos os nomes de tag usam PascalCase (primeira letra maiúscula), igual ao padrão do XSD. Tags com inicial minúscula (cepObra, logradouroObra etc.) causam rejeição pelo sistema Centi pois XML é case-sensitive. Não confundir também com os nomes do XML de retorno da API (cnoFild, cepObraFild, logradouroObraFild etc.), que usam o sufixo "Fild".
O XML de envio agora suporta informações sobre intermediário de serviços através da nova tag <Intermediario>.
- Tag principal:
<Intermediario>- Contém dados do intermediário de serviços <IdentificacaoIntermediario>- Grupo com CPF/CNPJ e Inscrição Municipal do intermediário<RazaoSocial>- Razão social do intermediário
Alguns campos foram removidos do XML de envio para simplificação e adequação ao padrão nacional.
<NaturezaOperacao>- Removido do nível principal de InfDeclaracaoPrestacaoServico<Observacao>- Removido do nível principal (mantido apenas dentro de Servico)<NomeFantasia>- Removido do grupo Tomador
A partir de12/01/2026, o XML de retorno das notas fiscais incluirá uma nova tag <DadosNotaNacional> contendo informações sobre IBS, CBS e a chave de acesso nacional.
- Tag principal:
<DadosNotaNacional>- Contém dados referentes à nota nacional <AliqotaIBS>- Alíquota aplicada para calcular o IBS<AliquotaCBS>- Alíquota aplicada para calcular o CBS<ValorIBS>- Valor calculado do IBS<ValorCBS>- Valor calculado do CBS<ChaveAcessoNacional>- Chave de acesso do registro da nota nacional
As tags dentro de <DadosNotaNacional> tiveram seus nomes padronizados para melhor legibilidade. Os nomes antigos não devem mais ser utilizados.
<pAliqIBS>foi substituída por<AliqotaIBS><pAliqCBS>foi substituída por<AliquotaCBS><vIBS>foi substituída por<ValorIBS><vCBS>foi substituída por<ValorCBS><chAcesso>foi substituída por<ChaveAcessoNacional>
O XML de retorno foi enriquecido com novos campos informativos para melhor rastreabilidade e gestão das notas fiscais.
<DescricaoCancelamento>- Descrição do motivo de cancelamento da nota<DescricaoSubstituicao>- Descrição do motivo de substituição da nota<Discriminacao>- Discriminação detalhada do serviço prestado<Observacao>- Observações adicionais sobre a nota fiscal<ValorCredito>- Valor de crédito tributário (quando aplicável)<EnderecoPrestadorServico>- Endereço completo do prestador<OrgaoGerador>- Identificação do órgão que gerou a NFS-e
O XML de retorno agora inclui estruturas específicas para informações de cancelamento e substituição de notas fiscais.
<NfseCancelamento>- Contém informações completas sobre o cancelamento da nota<NfseSubstituicao>- Contém informações sobre a nota fiscal substituta<Confirmacao>- Dados da confirmação do cancelamento<DataHora>- Data e hora da confirmação do cancelamento<NfseSubstituidora>- Número da nota fiscal que substituiu
Quando enviados no XML de entrada, os dados da obra agora são retornados dentro do grupo <Prestador> no XML de retorno.
- Os mesmos campos enviados são retornados para confirmação
- Permite verificar se os dados da obra foram registrados corretamente
- Localização: dentro de
<DeclaracaoPrestacaoServico>→<Prestador>
A estrutura <ValoresNfse> foi simplificada, mantendo apenas os campos essenciais para o resumo dos valores da nota.
<BaseCalculo>- Base de cálculo do ISS<Aliquota>- Alíquota aplicada<ValorIss>- Valor do ISS calculado<ValorLiquidoNfse>- Valor líquido da nota fiscal
O XML de retorno agora possui estruturas específicas para mensagens de alerta e erro, facilitando o tratamento de problemas.
<ListaMensagemAlertaRetorno>- Lista de alertas não-críticos<ListaMensagemRetorno>- Lista de mensagens gerais (erros, avisos, confirmações)<Codigo>- Código identificador da mensagem<Mensagem>- Descrição da mensagem<Correcao>- Sugestão de correção (quando aplicável)
Fique atualizado!
- Esta seção é atualizada sempre que há mudanças importantes nos XMLs, endpoints ou regras de validação da API.
- No menu "Arquivos para Download", contém o XML de exemplo com as novas tags.
- Valide a estrutura de seu XML antes de enviá-lo no menu "Validador de XML". Lembrando que este processo é somente uma dica opcional e não obrigatória.
Validador de XML
Verifique a estrutura do seu XML, os formatos de NBS/INDOP/Classificação Tributária e a configuração da requisição antes de enviar à API. O processamento é 100% local; vínculos cadastrais são confirmados somente pelo provider da Centi.
Arraste o arquivo XML aqui ou clique para selecionar
Use este checklist para diagnosticar erros de transmissão — problemas que ocorrem na camada HTTP/JSON, não no XML em si. São os casos mais comuns de erro (1, 1) mesmo com XML estruturalmente correto.
XML com HTML-encoding dentro do campo JSON
Causa o erro: There is an error in XML document (1, 1)
ERRO CRÍTICO
O campo "xml" no body JSON está com o conteúdo HTML-encoded: os caracteres < > " estão sendo enviados como < > ". Quando o servidor extrai o valor do campo "xml" e tenta fazer o parse como XML, encontra < no lugar de < — causando falha imediata no parse na posição (1,1).
Como verificar no Postman: No body da requisição (raw → JSON), o valor do campo "xml" deve começar exatamente com <?xml ou <GerarNfseEnvio. Se começar com <?xml ou <GerarNfseEnvio, ainda está HTML-encoded e precisa ser corrigido.
Content-Type incorreto — body é JSON mas header diz XML
Header: Content-Type
ERRO CRÍTICO
O body enviado é JSON (com os campos senha, usuario e xml), mas o header Content-Type está configurado como application/xml. Isso faz o servidor tentar interpretar o JSON inteiro como XML — causando falha imediata.
XML desatualizado dentro da collection do Postman
Campo "xml" no body JSON
ATENÇÃO
O conteúdo do campo "xml" na collection pode estar usando uma versão antiga do XML — sem declaração <?xml...?>, sem namespace, ou com estrutura que não corresponde ao schema atual da Centi. Após corrigir o Content-Type e o HTML-encoding, substitua o conteúdo do campo "xml" pelo XML mais recente, validado pela aba "Estrutura do XML".
Caracteres de controle ou BOM no início do XML
Encoding UTF-8 / BOM
VERIFICAR
Alguns editores ou sistemas salvam arquivos XML com BOM (Byte Order Mark) UTF-8 (EF BB BF) no início. O parser XML do servidor interpreta o BOM como conteúdo inválido, causando erro na posição (1,1). Verifique se o arquivo XML não contém BOM — o conteúdo deve começar exatamente com <?xml ou com a tag raiz, sem caracteres invisíveis antes.
URL da requisição — UF e Tenant corretos
https://api.centi.com.br/nfe/gerar/{UF}/{Tenant}
VERIFICAR
Certifique-se de que a URL contém a UF em minúsculas e o Tenant (nome do município) correto para o prestador. Uma URL apontando para o município errado pode retornar erros de autenticação ou de validação de dados.
Resumo — checklist rápido antes de enviar
Conferir sempre antes de reportar erro
RESUMO
Verifique antes de cada envio: