Skip to main content
La emisión de un DE no es instantánea: e-Miti recibe tu request, persiste el documento en estado P (pendiente) y lo envía a SIFEN en segundo plano. SIFEN responde con la aprobación o el rechazo, y el estado del DE en e-Miti se actualiza. Tu integración tiene dos formas de obtener el estado final:

​
Opción A — Polling (recomendado para integraciones desacopladas)

  1. Emitís el DE:
    Recibís 200 con el cdc, un id_interno y el estado inicial:
  2. Consultás el estado periódicamente:
    o por CDC:
  3. Cuando el campo estado cambia de P a A (aprobado) o R (rechazado), terminó el flujo:
    • A → el DE es fiscalmente válido y el KuDE está disponible.
    • R → el DE fue rechazado por SIFEN; mirá motivo_rechazo y el tutorial de manejo de rechazos.
Frecuencia sugerida: cada 2–5 segundos los primeros 30 segundos, después backoff exponencial. La mayoría de los DE quedan en estado final en menos de 10 segundos.

​
Opción B — Modo sincrónico (wait=true)

Si tu integración prefiere bloquear hasta tener el estado final, usá el parámetro wait=true en el POST de emisión:
  • timeout es opcional, en segundos. Default 10, rango válido 1–25.
  • Si SIFEN responde dentro del timeout, recibís el estado final (A o R) directamente.
  • Si SIFEN no responde a tiempo, recibís 200 con estado: "P" y el header X-DE-Status: pending — ahí seguís con polling como en la opción A.
Útil para flujos de venta donde el cajero espera la confirmación en la pantalla, pero no lo uses como única estrategia: si SIFEN está degradado o cae temporalmente, tu request va a esperar todo el timeout y devolver P igual. Tener polling de respaldo es necesario en cualquier integración seria.

​
Lo que no hay (por ahora)

  • Webhooks: no hay callbacks HTTP cuando un DE cambia de estado.
  • Server-Sent Events / WebSockets: no hay canal push.
Si tu caso de uso requiere notificación inmediata (ej. liberar stock al recibir aprobación), el modo sincrónico con polling de respaldo es la mejor combinación hoy.