La API DIAN Colombia que corre en tu propia infraestructura

Tu LICENSE_KEY es un JWS firmado con Ed25519. El binario lo valida offline contra una public key embebida al compilar — no necesita internet para arrancar ni para firmar facturas. Hay un heartbeat opcional cada 24h que reporta uso y verifica si hay updates; si pierdes internet, el binario sigue funcionando 7 dias en modo grace, despues empieza a advertir, y a los 14 dias deja de firmar nuevas facturas. Las ya firmadas nunca se invalidan.

No. El binario corre en tu infraestructura (tu VPS, tu Docker, tu desktop). Tus certificados .p12, las facturas, los CUFEs, los emails de tus clientes — todo vive en tu Postgres local. Lo unico que viaja a nuestros servidores es el heartbeat con conteos agregados (cuantos NITs activos, cuantos docs emitidos en el mes, version del binario). Sin metadata de facturas, sin clientes, sin XMLs.

Mantenemos un manifest firmado Ed25519 en updates.lyroo.com.co. El binario lo consulta en cada heartbeat. Cuando publicamos un update (especialmente los criticos por cambios DIAN), tu binario lo detecta, te avisa en logs y opcionalmente lo descarga y aplica solo (verificando SHA256 + firma). En self-hosted decides tu cuando aplicar; en plan Scale puedes activar auto-update para criticos.

En sandbox no necesitas nada de la DIAN: el simulador local te devuelve respuestas sinteticas. Para produccion necesitas tres cosas que aporta tu cliente final: (1) certificado de firma digital .p12 vigente, (2) resolucion de facturacion electronica activa con su rango de numeracion y (3) Software ID y PIN registrados en el portal MUISCA.

Lo aporta tu cliente final. Cada NIT factura con su propio certificado, emitido a su nombre por una entidad certificadora autorizada en Colombia (Andes SCD, Certicamara, GSE, etc.). El binario lo recibe via PUT /companies/{id}/config/certificate y lo cifra at-rest con AES-256-GCM en tu propia BD. El password del certificado tambien queda cifrado. Nunca sale de tu infraestructura.

Minimo: 1 vCPU, 512 MB RAM, 10 GB disco, Postgres 14+. En la practica corre comodo en un VPS de $5/mes (DigitalOcean, Hetzner, Vultr) o en una Raspberry Pi 4. El binario es estatico Go, sin runtime. Tambien puedes embebirlo en una app desktop con Wails (la libreria dian-go-embedded). No requiere kubernetes ni docker — un systemd unit alcanza.

Si, en sandbox puedes registrar URLs locales (localhost, 127.0.0.1) o de tunneling (ngrok, cloudflared). Cada evento llega firmado con HMAC-SHA256 en el header X-Lyroo-Signature; valida la firma en tu handler usando el secret que recibes al registrar el webhook. En produccion solo aceptamos URLs HTTPS publicas.

Te enviamos avisos por email a 80% y 95% del cupo. Si llegas al 100% no te bloqueamos a mitad de mes: te ofrecemos pasar al siguiente plan o pagar overage por documentos extra hasta fin de mes. La idea es que nunca interrumpamos tus facturas reales por una decision de billing.

Depende del plan: Sandbox 3, Starter 1, Pro 10, Scale 50, Enterprise ilimitado. Cada NIT tiene su propio certificado, resolucion, SMTP, logo, origenes CORS y aislamiento por company_id en todas las queries. Es multi-tenant nativo, no un parche encima de monotenant.

Del email de tu cliente. Cada NIT configura su propio SMTP via PUT /companies/{id}/config/smtp y todas las facturas de ese NIT salen desde esa cuenta. El password SMTP se cifra con AES-256-GCM antes de guardarse. Si un NIT no configura SMTP propio, cae al SMTP global como fallback.

No. CORS solo aplica si tu integracion corre en navegador. Si llamas server-to-server (backend, scripts, jobs, Postman) no necesitas configurar nada de CORS, solo un JWT valido. Si tu app es SPA o web, cada NIT registra sus dominios via PUT /companies/{id}/config/cors-origins y el servidor responde headers CORS solo cuando el Origin esta en el allow-list.

Los siete principales: Factura electronica (Tipo 01), Documento Soporte (Tipo 05), POS 80mm (Tipo 20), Contingencia con batch send (Tipo 25), Notas Credito (91), Notas Debito (92), Nota Credito de Documento Soporte (95) y Nomina electronica con CUNE (Tipo 102). Todos generan XML UBL 2.1 conforme DIAN, firmado XAdES-EPES y transmitido via SOAP con WS-Security.

Si, en plan Enterprise. La validacion de licencia es offline (JWS Ed25519 contra public key embebida) asi que arranca sin internet. Lo que pierdes en air-gapped: heartbeat de uso (no podemos saber tu consumo) y updates automaticos (te enviamos el binario nuevo por canal seguro cuando DIAN cambia). Tambien necesitas conexion al WS DIAN para transmitir facturas reales — eso es de DIAN, no nuestro.

Tenemos un circuit breaker alrededor del SOAP DIAN: si falla 5 veces seguidas, se abre por 30 segundos para no saturar. Las requests durante ese tiempo se rechazan rapidamente con codigo claro para que tu app reintente o entre en flujo de contingencia (Tipo 25). Cuando la DIAN se recupera, el batch-send envia las contingencias acumuladas.

Limite de payload: 10 MiB por request (configurable). En la practica eso son varios miles de items por factura. Si necesitas mas, hablamos en Enterprise.