Test helpers

Base: https://api.facturia.cl/v1. Todos los endpoints de este capítulo se autentican con Authorization: Bearer salvo que se diga lo contrario, y el sobre de error es el de Errores.

POST /test_helpers/received_documents

Inyecta un DTE de proveedor como si hubiera llegado a la casilla de recepción

Solo en sandbox: inyecta un DTE de proveedor como si acabara de llegar a la casilla de recepción, sin esperar que una contraparte real lo envíe.

curl -sS -X POST https://api.facturia.cl/v1/test_helpers/received_documents \
  -H "Authorization: Bearer $FACTURIA_KEY" \
  -H "Facturia-Empresa: $EMPRESA" \
  -H "Content-Type: application/json" \
  -d '{"tipo_dte":33,"emisor":{"rut":"96790240-3","legal_name":"Proveedor Austral SpA"}}'

Parámetros

Cuerpo

POST /test_helpers/rcv/seed

Siembra filas de RCV en un período para que la propuesta de F29 tenga datos

Solo en sandbox: siembra los registros de compras/ventas con entradas sintéticas, para poder probar flujos que dependen del RCV (caracterización, F29) sin una sincronización real con el SII.

curl -sS -X POST https://api.facturia.cl/v1/test_helpers/rcv/seed \
  -H "Authorization: Bearer $FACTURIA_KEY" \
  -H "Facturia-Empresa: $EMPRESA" \
  -H "Content-Type: application/json" \
  -d '{"period":"2026-07"}'

Parámetros

Cuerpo

POST /test_helpers/clock

Adelanta el reloj simulado de esta empresa

Ejercita la ventana de acuse de 8 días, el vencimiento de folios y los plazos del F29 sin esperar.

curl -sS -X POST https://api.facturia.cl/v1/test_helpers/clock \
  -H "Authorization: Bearer $FACTURIA_KEY" \
  -H "Facturia-Empresa: $EMPRESA" \
  -H "Content-Type: application/json" \
  -d '{"advance_days":9,"set_to":"…"}'

Parámetros

Cuerpo

POST /test_helpers/empresas/{empresa_id}/onboarding

Lleva la puesta en marcha de una empresa a cualquier estado

Solo en sandbox: fuerza el estado de puesta en marcha de la empresa a un onboarding_status dado, saltándose todos los pasos intermedios.

curl -sS -X POST https://api.facturia.cl/v1/test_helpers/empresas/emp_01K2R6ZC4P8QW1VN7T3MHDY9EK/onboarding \
  -H "Authorization: Bearer $FACTURIA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"status":"draft"}'

Parámetros

Cuerpo

POST /test_helpers/empresas/{empresa_id}/onboarding/steps

Fuerza el estado de un paso concreto de la puesta en marcha

La más fina de las dos palancas de puesta en marcha. POST .../onboarding mueve el ESTADO de la empresa; esta mueve UN PASO, que es como se producen las partes de §7.4 que un estado no alcanza a expresar: un paso en action_required con su action_url, una prueba de certificación que failed para un tipo_dte mientras los demás pasaron, o un paso skipped porque el RUT ya era emisor autorizado.

Los cuatro pasos de certificación (set_de_pruebas, simulacion, intercambio, muestras_impresas) existen por tipo de documento. Omite tipo_dte para forzar todos los tipos declarados de una vez; inclúyelo para forzar uno.

Devuelve el objeto de puesta en marcha completo y dispara el mismo webhook empresa.onboarding.* que dispararía la máquina real.

curl -sS -X POST https://api.facturia.cl/v1/test_helpers/empresas/emp_01K2R6ZC4P8QW1VN7T3MHDY9EK/onboarding/steps \
  -H "Authorization: Bearer $FACTURIA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"step":"mandato","status":"pending"}'

Parámetros

Cuerpo

POST /test_helpers/documents/{document_id}/estado

Fuerza el estado crudo del SII de un documento de sandbox ya emitido

test.outcome en POST /documents fuerza un resultado AL EMITIR. Esto fuerza uno DESPUÉS, y es la única manera determinista de ejercitar la transición que de verdad le importa a quien consume webhooks: sin esto, sent → accepted es correrle al asentamiento de ~1 s del sandbox, y stuck → accepted es inalcanzable.

ESCRIBE EL ESTADO, NO EL STATUS, a propósito. El status público se deriva después con el mapeo de siempre, así que una prueba que lleva un documento a DNK demuestra que el mapeo a reparo funciona en vez de afirmarlo. Se publica el mismo evento document.* del ciclo de vida que dispararía la transición real, así que quien esté bajo prueba recibe exactamente lo que manda producción.

Solo sandbox, revisado tres veces: el modo de la llave, la bandera de la empresa y el is_sandbox del PROPIO documento — que se estampa al insertar y es inmutable, así que un documento real sigue siendo real aunque después se cambie la bandera de la empresa.

curl -sS -X POST https://api.facturia.cl/v1/test_helpers/documents/doc_01K2R7Q4XW9M3B8ZC5YHTVJD6N/estado \
  -H "Authorization: Bearer $FACTURIA_KEY" \
  -H "Facturia-Empresa: $EMPRESA" \
  -H "Content-Type: application/json" \
  -d '{"estado":"DOK"}'

Parámetros

Cuerpo

POST /test_helpers/f29/proposals

Inject a computed F29 propuesta

Calcular una propuesta es un job del WORKER, y el worker no es parte de la promesa del sandbox (§4.1: el modo de prueba es «una simulación completa en proceso»). Sin este helper, el sandbox puede sembrar un RCV y quedarse esperando para siempre una propuesta que solo produce un worker corriendo, lo que deja intestable toda la superficie de §12.3/§12.4 en modo de prueba.

Escribe la misma fila que escribe el cálculo real, así que todo lo que viene después —el serializador, el enlace al archivo de carga y sobre todo la PUERTA DE DECLARACIÓN— lee una propuesta ordinaria. La puerta no se salta: sigue leyendo total_payable y observations de esta fila, y sigue exigiendo una validación (ver /test_helpers/f29/validations).

Volver a sembrar el mismo período lo actualiza en vez de crear un segundo.

curl -sS -X POST https://api.facturia.cl/v1/test_helpers/f29/proposals \
  -H "Authorization: Bearer $FACTURIA_KEY" \
  -H "Facturia-Empresa: $EMPRESA" \
  -H "Content-Type: application/json" \
  -d '{"period":"2026-07"}'

Parámetros

Cuerpo

POST /test_helpers/f29/validations

Fuerza el veredicto de la validación cruzada de un período

La validación cruzada real SE SALTA la consulta al SII en una empresa de sandbox y siempre registra unavailable — correctamente, porque una empresa de sandbox no tiene un SII contra el cual contrastarse. Pero unavailable no es validated, así que sin este helper la puerta de declaración rechaza TODA declaración de sandbox con not_validated y al resto de la §12.4 no se llega nunca.

Forzar el VEREDICTO en vez de la declaración es lo que lo mantiene honesto: una prueba que lleva una propuesta a validated y después declara demuestra que la puerta deja pasar una propuesta validada, y una que la deja en unavailable demuestra que la puerta detiene a la que no lo está. La puerta misma no se toca en ninguno de los dos casos.

curl -sS -X POST https://api.facturia.cl/v1/test_helpers/f29/validations \
  -H "Authorization: Bearer $FACTURIA_KEY" \
  -H "Facturia-Empresa: $EMPRESA" \
  -H "Content-Type: application/json" \
  -d '{"period":"2026-07"}'

Parámetros

Cuerpo