> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fire.rest/llms.txt
> Use this file to discover all available pages before exploring further.
# Integrar-se como provedor fiscal
> O que um provedor fiscal implementa para se conectar ao Fiscal Gateway do FIRE, e por que o contrato está definido assim.
**Esta seção é para provedores fiscais**, não para pontos de venda. Se você está
integrando um PDV ou um totem que *consome* a numeração do FIRE, o seu caminho é o
[guia de integração fiscal](/pt/guides/fiscal-integration).
## As duas integrações, que não são a mesma coisa
Existem duas conexões distintas e opostas em torno da numeração fiscal:
```
ponto de venda ──consome──▶ FIRE ──consome──▶ provedor fiscal ──▶ órgão tributário
(guia fiscal) (esta seção)
```
O ponto de venda pede números ao FIRE para imprimir. O FIRE pede esses números ao provedor
fiscal, que é quem fala com o órgão tributário de cada país.
Esta seção define **a segunda seta**: o que enviamos a um provedor e o que esperamos
de volta.
## É um contrato canônico
Ele não descreve o que um provedor em particular faz: **é o requisito**. Qualquer um que se
integre ao Fiscal Gateway implementa este mesmo endpoint, com esta mesma forma. Ele não
muda por provedor nem por país.
Isso tem uma consequência que convém entender antes de ler o detalhe:
**O contrato usa o vocabulário do FIRE, não o do órgão tributário.** Não trafegam códigos
do SRI (fisco do Equador), da DIAN (fisco da Colômbia) nem da SEFAZ. Não trafegam identificadores do catálogo
do provedor.
O provedor **traduz** para o que cada país exigir — essa é justamente a sua função. Um
contrato que falasse o idioma de um órgão deixaria de servir para o próximo.
Por isso o request leva `operation: "INVOICE"` e não `documentTypeCode: "01"`; `store.code`
e não `establishmentCode`; `device.externalId` e não `pointOfEmissionCode`.
Os nomes dos campos são os mesmos que os eventos do FIRE já usam
([`order.completed`](/pt/events/order-completed), [`order.invoiced`](/pt/events/order-invoiced)).
Quem já consome eventos não aprende vocabulário novo.
## O que precisa ser implementado
Um endpoint por país, síncrono:
```
POST {baseUrl}/api/v1/fiscal/{country}/prekeys
```
```
POST {baseUrl}/api/v1/fiscal/ec/prekeys Equador
POST {baseUrl}/api/v1/fiscal/co/prekeys Colômbia
```
**Uma única integração**: uma `baseUrl`, uma credencial. As rotas que existem são os países
que você atende, então um país novo é adicionado sem tocar nos que já funcionam.
Ele recebe uma venda e devolve os identificadores fiscais para imprimi-la. Está **no
caminho crítico da venda** — o caixa está esperando — então o orçamento de latência
alvo é de **menos de 3 segundos**.
Este endpoint produz a **representação fiscal**: os números para imprimir. O envio ao
órgão e a sua autorização acontecem depois, do lado do provedor, e o desfecho chega pelo
callback. São dois ciclos de vida distintos e o contrato não os mistura.
## Por onde seguir
Autenticação, request, resposta, erros e idempotência. O requisito completo.
Como aquilo que você devolve acaba trafegando nos eventos do pedido.
Requisições e respostas capturadas de uma integração em funcionamento.