SIFENDE
Guías

Ir a Producción

Checklist completo para pasar tu integración de Sifende al ambiente de producción — credenciales, manejo de errores y pruebas finales.

Pasar del entorno de pruebas a producción significa que tus DE empiezan a tener validez fiscal real. Errores en producción afectan tu IVA, tus declaraciones y la relación con tus clientes. Acá tenés el checklist antes del go-live.

Una vez en producción, los documentos son legales. No podés emitir "de prueba" en producción: todo lo que enviás se envía a SIFEN como real. Hacé todas las pruebas en el entorno de pruebas antes de activar producción.

No hay una URL separada para pruebas. Sifende usa la misma URL base (https://api.sifende.com.py) para ambos entornos. Elegí Pruebas o Producción desde el panel y Sifende enviará cada emisión al entorno correspondiente. Todas las API keys usan el prefijo sk_live_.

Pre-requisitos

Antes de empezar, asegurate de tener:

  • Tu integración funcionando 100% en el entorno de pruebas (todos los flujos críticos probados allí)
  • Acceso al portal MARANGATÚ de la SET (para timbrado y certificado)
  • Acceso al portal e-Kuatia (para CSC de producción)
  • Certificado digital vigente (PKCS12 con clave)
  • Timbrado de producción otorgado por la SET

Checklist de migración

Obtené el CSC de producción. Ingresá al portal e-Kuatia con tu certificado, andá a "Códigos de Seguridad", y generá un CSC de producción. Anotá el ID y el código: los necesitás en Sifende.

Verificá tu certificado digital en Sifende:

  1. Configuración → Certificado Digital
  2. Si todavía no está cargado, subí el archivo .p12 o .pfx
  3. Ingresá la contraseña del certificado
  4. Verificá que la fecha de vencimiento sea correcta

⚠️ El mismo certificado puede usarse en pruebas y producción. No hace falta reemplazarlo al activar producción; verificá que siga vigente.

Registrá el timbrado de producción en Sifende:

  1. Configuración → Timbrados
  2. Cargá el número de timbrado obtenido en MARANGATÚ
  3. Ingresá establecimiento, puntoExpedicion, rango (desde/hasta), fechaInicio y fechaFin
  4. Activalo

Creá una API key para la integración en Sifende:

  1. Configuración → API Keys
  2. Generá una nueva key
  3. Copiala inmediatamente. Solo se muestra una vez
  4. Guardala como secreto (variables de entorno, vault, etc.)

⚠️ Todas las API keys usan el prefijo sk_live_ y no codifican el entorno. Antes de emitir, confirmá en el panel si estás en Pruebas o Producción.

Actualizá tu integración:

# Variables de entorno
SIFENDE_BASE_URL=https://api.sifende.com.py
SIFENDE_API_KEY=sk_live_...

Cambiá la URL base y la API key. Recompilá / redeployá tu aplicación.

Emití tu primer DE de producción con un cliente conocido (ej: tu propia empresa o un cliente de confianza). Verificá que:

  • El estado pasa a APROBADO
  • El KuDE se genera correctamente
  • El DE aparece en el portal e-Kuatia

Monitoreá las primeras 24-48 horas activamente. Cualquier rechazo masivo indica un problema que hay que detener antes de que escale.

URL base

Sifende usa una sola URL base para los dos entornos:

https://api.sifende.com.py

El entorno de destino se selecciona desde el panel. Cuando cumplas los requisitos, usá la opción Pasar a Producción para comenzar a emitir documentos con validez fiscal.

No hay una URL qa.sifende.com.py ni un prefijo sk_test_. Si tu integración apuntaba a una URL distinta a la oficial, actualizala antes del go-live.

Checklist crítico antes del go-live

Credenciales

  • API key guardada en variables de entorno (no en código)
  • Certificado digital vigente
  • Timbrado de producción registrado y activo
  • CSC de producción configurado

Manejo de errores

  • Implementaste y probaste el contrato de Idempotencia y Reintentos Seguros para emisión, cancelación e inutilización
  • Manejo de 429 Too Many Requests
  • Polling de estado implementado (ver Polling de Resultados)
  • Persistís el id y cdc de cada DE antes de pollear
  • Loggeás todos los rechazos con código y motivo

Calidad de datos

  • Validación de RUC en el frontend (formato {número}-{dv})
  • Montos en PYG son enteros sin decimales
  • Fechas en formato ISO 8601 sin timezone (2026-04-15T10:30:00)
  • Campos B2B completos cuando corresponde (razón social, dirección, tipo contribuyente)
  • Solo usás condicionPago: CONTADO por ahora; el soporte para CREDITO está en desarrollo

Solo CONTADO está completamente soportado en producción. La condición de pago CREDITO (cuotas, plazos) está en el roadmap pero no es estable hoy. Si tu negocio requiere ventas a crédito, esperá la próxima versión o contactá a soporte.

Flujos probados

  • Factura Electrónica B2C (con receptor INNOMINADO)
  • Factura Electrónica B2B
  • Nota de Crédito sobre una FE aprobada
  • Nota de Débito sobre una FE aprobada
  • Cancelación de un documento aprobado
  • Inutilización de rango de numeración
  • Reemisión después de un rechazo
  • Descarga de KuDE PDF

Notificaciones

  • Si activaste email al receptor, probaste que llega correctamente
  • El template de email tiene tu branding y datos de contacto

Seguridad

  • La API key NO está en el código fuente ni en repositorios git
  • Tenés un plan de rotación de API keys
  • El certificado digital está almacenado de forma segura
  • Configuraste alertas para errores 5xx y 401

Operaciones

  • Tenés un dashboard para ver tasa de aprobación / rechazo
  • Tenés un plan para días de baja de SIFEN (rara pero pasa)
  • Documentaste internamente el procedimiento para incidentes

Runbook de rollout de idempotencia

El guard es fail-closed: mientras una revisión no pueda honrar Idempotency-Key, debe rechazar el request sin ejecutar la operación. No habilites la feature mientras una revisión que ignore el header pueda recibir tráfico.

Este procedimiento presupone que los clientes aplican el contrato de Idempotencia y Reintentos Seguros.

Etapa 1: desplegar capacidad con la feature apagada

  1. Desplegá una revisión que reconozca Idempotency-Key y mantenga la feature apagada.
  2. Confirmá que un request con el header recibe 503 idempotency-unavailable y produce cero documentos, correlativos o eventos.
  3. Drená todas las revisiones antiguas que ignoran el header.
  4. Verificá que el 100% del tráfico llega a revisiones guard-capable antes de avanzar.

Durante esta etapa, los clientes pueden persistir y enviar claves: el rechazo explícito permite reintentar después con la misma clave sin un efecto oculto.

Etapa 2: habilitar la feature

  1. Habilitá la feature sólo después del drenaje completo.
  2. Probá a baja escala emisión, cancelación e inutilización, incluidos replay, respuesta perdida y Retry-After.
  3. Monitoreá errores por tipo: in-progress, upstream-unknown, outcome-unknown, key-expired, key-reused y unavailable.
  4. Aumentá tráfico únicamente si no hay duplicados y los retries conservan clave y payload.

Rollback

Un rollback sólo puede dirigir tráfico a una revisión que reconozca el header y mantenga el guard fail-closed. Si necesitás deshabilitar la feature, apagála primero en una revisión compatible; no reviertas a una versión que ignore Idempotency-Key. Volver a una revisión incompatible permitiría que un retry se ejecute como una operación nueva.

Este runbook documenta el procedimiento; no ejecuta despliegues ni cambios de tráfico.

Pruebas finales recomendadas

Antes del go-live oficial, ejecutá estos casos en producción con datos reales pero a baja escala:

  1. DE B2C de monto bajo. Verificá que llega APROBADO y el KuDE es válido.
  2. DE B2B con cliente conocido. Confirmá que el cliente recibe el documento por email (si aplica) y puede consultarlo en e-Kuatia.
  3. Cancelación. Cancelá el primer DE de prueba y emití uno nuevo.
  4. Verificación cruzada. Entrá al portal e-Kuatia y confirmá que tus DE aparecen ahí.

Si algo sale mal

Soporte

¿Necesitás ayuda con el go-live?

Próximos pasos

Reintentar Documentos Rechazados

Flujo completo para corregir un documento rechazado por SIFEN y reemitirlo con un nuevo CDC.

Referencia API

Documentación completa de todos los endpoints de la API de Sifende — schemas, ejemplos de código y referencia de errores.

On this page

Pre-requisitosChecklist de migraciónURL baseChecklist crítico antes del go-liveCredencialesManejo de erroresCalidad de datosFlujos probadosNotificacionesSeguridadOperacionesRunbook de rollout de idempotenciaEtapa 1: desplegar capacidad con la feature apagadaEtapa 2: habilitar la featureRollbackPruebas finales recomendadasSi algo sale malSoportePróximos pasos