# Prueba los casos infelices > RUTs mágicos del sandbox para forzar rechazo, con reparos, folios agotados o un DTE atascado en procesando — más el catálogo de errores estructurados que tu integración debe manejar. Un DTE `aceptado` en el primer intento es el camino feliz. En producción vas a ver rechazos, documentos con reparos, folios agotados y respuestas lentas del SII — y tu integración necesita manejarlos **antes** de que ocurran contra un cliente real. El sandbox trae **RUTs de receptor reservados** que disparan cada resultado de forma determinística. Los RUTs mágicos no le mienten a la máquina de estados de Simplo: se le miente al simulador del SII. El ciclo real — `firmado → enviando → procesando → aceptado/rechazado/con_reparos`, con los mismos eventos y el mismo código de transición — corre exactamente igual que en producción. Lo único fabricado es la respuesta que el SII (simulado) da. ## RUTs mágicos: fuerza el resultado desde la emisión Emite un DTE con uno de estos RUTs como `receptor.rut` y el resultado queda determinado desde el momento en que lo envías — sin llamar ningún endpoint extra: | RUT receptor | Resultado | Código SII | | ------------- | --------------------------------------------------- | ---------- | | `44000001-0` | `rechazado` | `EMP` | | `44000002-9` | `con_reparos` | `DNK` | | `44000003-7` | se queda en `procesando` (el simulador nunca resuelve) | `DOK` (no terminal) | | `44000004-5` | el envío al SII simulado falla como si no quedaran folios (`CAF_NO_DISPONIBLE`) | — (el envío falla) | | cualquier otro | camino feliz: `enviando → procesando → aceptado` | `DOK` | ```bash curl -X POST https://api.simplo.cl/api/v1/billing/dte \ -H "X-Api-Key: $SIMPLO_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "tipo_dte": 33, "receptor": { "rut": "44000001-0", "razon_social": "Cliente que rechaza" }, "detalle": [{ "nombre": "Prueba de rechazo", "cantidad": 1, "precio": 10000 }] }' ``` `44000004-5` es el caso distinto de los otros tres: los demás emiten normalmente (`201`, `estado: "firmado"`) y el veredicto diverge más tarde, durante el ciclo asíncrono — igual que en producción. `44000004-5` en cambio hace fallar **el envío al SII simulado** con un error de folios agotados (`CAF_NO_DISPONIBLE` — ver la tabla de errores abajo): la emisión retorna `201`, pero el documento nunca avanza a `procesando`. Es la manera de ensayar el escenario "me quedé sin folios" sin agotar tus folios sintéticos de prueba. Los RUTs mágicos aceptan el formato con o sin puntos/espacio (`44.000.001-0` o `44000001-0` calzan igual). Los RUTs mágicos son la **única** palanca del sandbox: no hay endpoints para forzar estados sobre un DTE ya emitido ni para reiniciar el sandbox. Si necesitas un resultado específico, decídelo al emitir, con el RUT del receptor. ## Catálogo de errores estructurados Toda falla de la API — sandbox o producción — responde con la misma forma: `code` (legible por máquina), `message`, `action` (siguiente paso recomendado) y `severity`. Estos son los que vas a encontrar probando los casos infelices: | Código | Mensaje | Acción recomendada | Severidad | | --------------------------- | ------------------------------------------------------------ | ------------------------ | ---------- | | `CAF_NO_DISPONIBLE` | No hay CAF disponible para el tipo de documento | `upload_caf` | error | | `CAF_STOCK_LOW` | Folios por agotarse | `upload_caf` | warning | | `DTE_NOT_FOUND` | DTE no encontrado | `verify_empresa_and_id` | error | | `DTE_ESTADO_INVALIDO` | DTE en estado que no permite esta operación | `check_dte_status` | error | | `RUT_INVALIDO` | RUT no pasa validación módulo-11 | `fix_rut_input` | error | | `FOLIO_DUPLICADO` | Folio ya utilizado | `check_existing_dte` | error | | `MONTO_INCONSISTENTE` | Neto + IVA no coincide con el total | `recalculate_totals` | error | | `IDEMPOTENCY_IN_PROGRESS` | La solicitud con esta `Idempotency-Key` ya se está procesando | `retry_later` | warning | | `IDEMPOTENCY_BODY_MISMATCH` | La `Idempotency-Key` fue reutilizada con un body distinto | `generate_new_key` | warning | | `SII_RECHAZADO` | El SII rechazó el documento | `review_xml_errors` | error | | `SII_DUPLICADO` | El documento ya fue enviado al SII | `check_existing_envio` | warning | El catálogo completo (incluyendo certificado, exportación, liquidaciones y más) vive en [Errores](/referencia/errores/). `action` está pensado para que un coding agent decida el siguiente paso sin tener que interpretar `message` en lenguaje natural. ## Lo que el sandbox NO simula Un sandbox que promete de más produce el mismo abandono que viene a evitar. Sé explícito con esto en tu propia integración: - **Validación XSD y reglas de negocio del SII real.** El simulador acepta el XML que el motor generó; el SII real rechaza por causas que solo aparecen contra el ambiente de certificación o producción del SII. - **La certificación SII.** Pasar el sandbox no acerca ni un día a estar certificado ante el SII — ver [Pasar a producción](/comienza/pasar-a-produccion/). - **Vencimiento real de folios** (6 meses) ni de certificados: los del sandbox son sintéticos y de larga vigencia. - **Caídas, latencia y rate limits reales del SII**, ni sus códigos finales 904/905/906. - **Intercambio** (correo, acuses de recibo, SETMAIL). - **El PDF y el XML no tienen validez tributaria** — el CAF y el certificado del sandbox son sintéticos, autofirmados, y el SII real los rechazaría. Los montos y el IVA sí son de verdad: es el mismo motor de cálculo que producción, y lo único ficticio es el receptor. ## Relacionado - [Quickstart](/comienza/quickstart/) — el flujo completo, del sandbox a tu primer DTE - [Estados](/referencia/estados/) — el ciclo de vida completo de un DTE - [Errores](/referencia/errores/) — el catálogo completo y las reglas de reintento - [Pasar a producción](/comienza/pasar-a-produccion/) — la checklist de go-live --- Versión HTML: https://docs.simplo.cl/comienza/casos-infelices/ · Índice para agentes: https://docs.simplo.cl/llms.txt