Integrar facturación electrónica con SIFEN no debería obligar a cada consumidor de una API a conocer cómo se almacena un certificado, cuál es su contraseña o qué credenciales técnicas utiliza el emisor. Ese acoplamiento vuelve más frágil la integración y aumenta innecesariamente la superficie de exposición.
En el núcleo abierto de Egeek.Sifen completamos un perfil monoemisor para la Web API: la identidad fiscal, el timbrado y las credenciales criptográficas se resuelven en el servidor. Los clientes envían los datos funcionales del documento y el host se responsabiliza de firmarlo y comunicarse con SIFEN mediante una única credencial coherente.
Qué quedó incorporado
- Configuración monoemisor resuelta por el host, sin transportar certificados ni contraseñas en cada request.
- Uso consistente de la misma credencial para la firma XML y la autenticación mutua TLS.
- Resolución de timbrados y datos reservados fuera de los DTO públicos.
- Health checks nativos de ASP.NET Core para disponibilidad y preparación del servicio.
- Validaciones para documentos asociados en factura electrónica, alineadas con los campos específicos del esquema SIFEN.
Cómo lo verificamos
La solución superó 137 pruebas locales. Además, ejecutamos el preflight completo con firma digital, generación del QR y validación contra los XSD oficiales. Finalmente se realizó un envío real al ambiente de pruebas de SIFEN y se obtuvo la respuesta 0260, correspondiente a una autorización satisfactoria del documento electrónico.
Límites actuales y próximos pasos
El perfil implementado es monoemisor por instancia y todavía no contempla rotación dinámica de credenciales ni escenarios multiempresa. Los health checks verifican la configuración local y no realizan llamadas activas a SIFEN. Los siguientes bloques previstos son la firma múltiple y, después, el procesamiento por lotes.
La documentación técnica oficial de referencia está disponible en el portal de e-Kuatia de la DNIT.