> ## Documentation Index
> Fetch the complete documentation index at: https://docs.emiti.fravelabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Flujo asíncrono de emisión

> Cómo seguir un DE desde el request hasta el estado final en SIFEN.

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:
   ```bash theme={null}
   POST /v1/de/emitir
   ```
   Recibís 200 con el `cdc`, un `id_interno` y el estado inicial:
   ```json theme={null}
   {
     "id": "01HXY...",
     "id_interno": "FAC-2026-0001",
     "cdc": "0180012345...",
     "estado": "P"
   }
   ```

2. **Consultás** el estado periódicamente:
   ```bash theme={null}
   GET /v1/de?id_interno=FAC-2026-0001
   ```
   o por CDC:
   ```bash theme={null}
   GET /v1/de?cdc=0180012345...
   ```

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](/tutoriales/manejo-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:

```bash theme={null}
POST /v1/de/emitir?wait=true&timeout=15
```

* `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.