# Confirmaciones de dos pasos (/docs/mcp/confirmaciones)

## El default: ejecución directa [#el-default-ejecución-directa]

Cuando un agente llama `emit_document`, emite.

Facturia no interpone su propio paso de aprobación, porque la UI de aprobación de herramientas del
cliente MCP — eso que te muestra «Claude quiere llamar `emit_document`, ¿permitir?» — **es** el humano
en el ciclo. Agregar una segunda confirmación del lado de Facturia sobre eso, para cada escritura,
sería redundante en la enorme mayoría de las llamadas y derrotaría la mitad del punto de una interfaz
de agente.

## Dónde eso no alcanza [#dónde-eso-no-alcanza]

Existen dos modos de falla distintos, y la aprobación del cliente solo resuelve uno:

**El agente intenta hacer algo que la persona no pidió.** Lo resuelve el paso de aprobación del propio
cliente — para eso existe exactamente.

**La persona aprueba por reflejo todo lo que su cliente de chat le pregunta, y algo con consecuencia
financiera real — declarar un formulario tributario, un reclamo irreversible — sale porque alguien
hizo clic en «permitir» en piloto automático y no porque haya revisado deliberadamente esa cifra.**
La aprobación del cliente **no** resuelve esto: es el mismo clic en ambos casos.

`require_confirmation` ataca el segundo.

## Encenderlo [#encenderlo]

Es una bandera por empresa en `automation_settings`, al lado de `auto_emit_46` y compañía. Viene
**apagada**, como toda automatización.

```bash
curl -X PATCH https://api.facturia.cl/v1/empresas/emp_01K2R6.../automation_settings \
  -H "Authorization: Bearer $FACTURIA_KEY" -H "Content-Type: application/json" \
  -d '{"require_confirmation": true}'
```

Es un campo REST, no un ajuste solo de MCP: los llamadores REST y el panel ven y controlan la misma
bandera. La API REST descrita en el resto de esta documentación no cambia de comportamiento por
encenderla.

## Qué herramientas toca [#qué-herramientas-toca]

`emit_document`, `file_f29`, `emit_tipo46` y `reclaim_received_document` — el conjunto «emitir /
declarar / reclamar».

Toda otra escritura (`accept_received_document`, por ejemplo) sigue siendo directa aunque la bandera
esté encendida: aceptar ya coincide con el default legal que ocurriría por silencio de todas formas,
así que ponerle un cerrojo no protege nada.

## Cómo se ve [#cómo-se-ve]

```jsonc
// → file_f29
{ "empresa": "77928532-4", "period": "2026-07", "confirm_total_payable": 1373000 }

// ← pending_confirmation (la empresa tiene require_confirmation: true)
{
  "status": "pending_confirmation",
  "confirmation_id": "conf_01K2SD3P7Q",
  "confirmation_url": "https://app.facturia.cl/aprobar/conf_01K2SD3P7Q?token=mcpapv_9lQpV3fA…",
  "action": "file_f29",
  "summary": "File F29 for período 2026-07 — CLP 1.373.000 payable, due 2026-08-20.",
  "expires_at": "2026-08-14T14:45:00Z"
}
```

Nada se declaró. El agente te entrega el resumen y el enlace, y ahí se detiene.

## Quién la completa: tú, en una página [#quién-la-completa-tú-en-una-página]

Abres `confirmation_url`, ves qué empresa, qué acción y con qué cifra, y aprietas **Confirmar** o
**Rechazar**. No hace falta iniciar sesión: el enlace lleva un token de un solo uso, válido esos 15
minutos y para esa acción y ninguna otra. Recién ahí se declara el F29 — con exactamente los datos
que se resumieron cuando el agente lo planteó, no con lo que haya en el mundo en ese momento.

> **El agente no puede completarla, y eso es el punto**
>
> No hay ninguna herramienta MCP que cierre una acción pendiente. La hubo — `confirm_action` — y se
> retiró: si el agente puede completarla diciendo «el usuario me dijo que sí», entonces el registro de
> tu aprobación es la palabra del agente, que es exactamente lo que esta bandera existe para no
> aceptar. Si le dices al agente que ya aprobaste, que lo verifique leyendo (`get_document_status`, o
> `file_f29` con un `filing_id`).

Confirmar dos veces reproduce el resultado original en vez de ejecutar dos veces — la misma garantía
que `Idempotency-Key` le da a un llamador REST. Rechazar dos veces tampoco es un error: querías que
no pasara, y no está pasando.

Una aprobación vence a los **15 minutos** sin recoger. Vencida, la página lo dice y el agente tiene
que volver a plantear la acción para generar una nueva.

## Sandbox: se ensaya acá [#sandbox-se-ensaya-acá]

El doble paso **funciona igual en sandbox**: si enciendes `require_confirmation` en una empresa de
prueba, la emisión se aparca, se acuña el enlace y la página `/aprobar` se abre como en live —
marcada como prueba, para que nadie confunda el ensayo con lo real.

> **Antes esto no se podía ensayar**
>
> Hasta septiembre de 2026 el sandbox ignoraba la bandera: la API la aceptaba, la devolvía encendida
> y la emisión salía directo igual. Es decir, el puente más delicado del producto — ese en el que un
> agente le pasa una decisión a una persona — solo se podía ver por primera vez con documentos de
> verdad. Ahora se prueba con cero riesgo.
>
> La demo de sesenta segundos no cambió: la bandera viene **apagada** por defecto, así que una empresa
> de sandbox recién creada sigue emitiendo en una sola llamada.

## Los estados que no son errores [#los-estados-que-no-son-errores]

Dos comportamientos de esta capa que conviene tener claros en el cliente:

* **Límite de tasa y confirmación pendiente no son fallas.** El equivalente a un `429` y las
  respuestas `pending_confirmation` son *resultados* ordinarios de la herramienta con un campo
  `status` claro, no errores lanzados. Un agente debería leerlos y decidir qué decir a continuación,
  no tratarlos como algo roto.
* **Cada descripción de herramienta declara sus propios modos de falla probables.** Un agente que
  elige entre `emit_document` y `draft_document`, o que decide si es seguro reintentar tras un
  `sii_error`, nunca debería tener que consultar documentación externa a media conversación. Por eso
  `retriable` viaja en cada motivo de rechazo.