Introducción

Fac-360 emite comprobantes de pago electrónicos ante SUNAT: factura, boleta, notas de crédito y débito, retención, percepción, resumen diario y comunicación de baja.

Las dos superficies

La plataforma publica dos APIs sobre el mismo host, cada una con su propio documento OpenAPI y su propio mecanismo de autenticación.

No son la misma API con dos puertas: tienen contratos distintos y privilegios distintos en la base de datos. Si estás integrando un ERP, la tuya es /api/v2.

Empieza por BETA

SUNAT expone un entorno de homologación (e-beta.sunat.gob.pe) donde un comprobante recorre el mismo camino que en producción y devuelve un CDR real. Todo el desarrollo se hace ahí.

Antes incluso de eso existe un paso más barato: POST /api/v2/documents/validations corre exactamente las mismas validaciones que la creación de un comprobante, responde con valid, findings y los totals calculados, y no crea nada — ni documento, ni correlativo, ni operación, ni consumo de cuota. Es la herramienta para construir un mapeo sin emitir.

Estado de esta documentación

La referencia se genera desde los contratos publicados y no se escribe a mano: cada página de /docs/api y /docs/console sale de APIFACT_OPENAPI_V2 y CONSOLE_OPENAPI_V1 en cada build, con sus ejemplos de request y sus snippets por lenguaje. Una referencia que se pudiera editar acabaría contradiciendo a la API, y el lector no tendría forma de saber cuál de las dos miente.

Los mismos documentos se publican tal cual, para un generador de clientes o para un agente:

Y en /llms.txt y /llms-full.txt está el sitio entero en texto plano, con la operación de cada página, si prefieres dárselo a un modelo.

Lo que todavía no está: snippets propios con nuestro SDK. El playground está desactivado a propósito — cuando se encienda hablará solo con BETA, porque un formulario público capaz de disparar contra la API real emite comprobantes que solo una comunicación de baja aceptada retira.

Por dónde empezar