> ## 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. # Integrarse como proveedor fiscal > Qué implementa un proveedor fiscal para conectarse con el Fiscal Gateway de FIRE, y por qué el contrato está definido así. **Esta sección es para proveedores fiscales**, no para puntos de venta. Si estás integrando un POS o un kiosco que *consume* la numeración de FIRE, lo tuyo es la [guía de integración fiscal](/es/guides/fiscal-integration). ## Las dos integraciones, que no son la misma Hay dos conexiones distintas y opuestas alrededor de la numeración fiscal: ``` punto de venta ──consume──▶ FIRE ──consume──▶ proveedor fiscal ──▶ ente tributario (guía fiscal) (esta sección) ``` El punto de venta le pide números a FIRE para imprimir. FIRE se los pide al proveedor fiscal, que es quien habla con el ente tributario de cada país. Esta sección define **la segunda flecha**: qué le enviamos a un proveedor y qué esperamos de vuelta. ## Es un contrato canónico No describe lo que hace un proveedor en particular: **es el requisito**. Cualquiera que se integre con el Fiscal Gateway implementa este mismo endpoint, con esta misma forma. No cambia por proveedor ni por país. Eso tiene una consecuencia que conviene entender antes de leer el detalle: **El contrato usa el vocabulario de FIRE, no el del ente tributario.** No viajan códigos del SRI, de la DIAN ni de la SEFAZ. No viajan identificadores del catálogo del proveedor. El proveedor **traduce** a lo que exija cada país — esa es precisamente su función. Un contrato que hablara el idioma de un ente dejaría de servir para el siguiente. Por eso el request lleva `operation: "INVOICE"` y no `documentTypeCode: "01"`; `store.code` y no `establishmentCode`; `device.externalId` y no `pointOfEmissionCode`. Los nombres de los campos son los mismos que ya usan los eventos de FIRE ([`order.completed`](/es/events/order-completed), [`order.invoiced`](/es/events/order-invoiced)). Quien ya consume eventos no aprende vocabulario nuevo. ## Qué hay que implementar Un endpoint por país, síncrono: ``` POST {baseUrl}/api/v1/fiscal/{country}/prekeys ``` ``` POST {baseUrl}/api/v1/fiscal/ec/prekeys Ecuador POST {baseUrl}/api/v1/fiscal/co/prekeys Colombia ``` **Una sola integración**: un `baseUrl`, una credencial. Las rutas que existen son los países que atendés, así que un país nuevo se agrega sin tocar los que ya funcionan. Recibe una venta y devuelve los identificadores fiscales para imprimirla. Está **en el camino crítico de la venta** —la caja está esperando— así que el presupuesto de latencia objetivo es de **menos de 3 segundos**. Este endpoint produce la **representación fiscal**: los números para imprimir. El envío al ente y su autorización ocurren después, del lado del proveedor, y su desenlace llega por el callback. Son dos ciclos de vida distintos y el contrato no los mezcla. ## Por dónde seguir Autenticación, request, respuesta, errores e idempotencia. El requisito completo. Cómo lo que devolvés termina viajando en los eventos de la orden. Peticiones y respuestas capturadas de una integración en funcionamiento.