Tupana Connect
El widget que abres en tu app para que tu usuario final conecte su empresa. La clave del SII (o del facturador, o del banco) viaja a Tupana. Tu backend nunca la ve. En v2 la clave no se manda por API: conectas con este widget y guardas elconnection_id (cred_…), que es lo único que tu SaaS conoce de la empresa.

Esto ve tu usuario. Tú solo recibes el cred_….
Integra en tres llamadas
1
Tu backend abre una sesión
POST /api/v2/connect-sessions/ con tu API key. Te devuelve un
client_token de 30 minutos. Si ya conoces el RUT, mándalo como tax_id
y el widget no lo vuelve a pedir.2
Tu frontend abre el widget
Iframe o ventana. El
token es el client_token. tax_id en la URL
gana sobre el de la sesión.3
Tu backend guarda la conexión
Cuando el SII valida la clave, el webhook trae el
cred_…. Con eso emites.
También puedes listarlas con
GET /connections/.Body de la sesión
Query del widget
Reautorizar un banco
Cuando una conexión de banco queda enrequires_action, no abras una sesión
desde cero: POST /connections/{connection_id}/reauthorizations/
te devuelve un client_token con la empresa y el banco ya elegidos, y la
conexión conserva su connection_id al terminar.
Lo que ve tu usuario
- SII gratuito
- Facturador de mercado
- Banco

- RUT de la empresa — no aparece si mandaste tax_id.

- Detectamos SII. El RUT del representante se formatea solo.
Cuándo el enrolamiento es exitoso
El widget no avisa éxito al recibir la clave. Se queda en pantalla mientras la institución responde. Si la clave está mala, el error queda adentro y el usuario reintenta: no haysuccess. success sale cuando el
flujo terminó; exit sale solo si la persona cierra antes.
El postMessage mueve tu modal. El webhook
dice si la credencial quedó.
SII
El login no termina en el request. La respuesta traestatus: "connecting"
y un enrollment_id (cenr_…). El widget espera en
ws/connect/{client_token}/ y manda success solo con valid.
GET /api/v2/connections/enrollments/{enrollment_id}/ hasta valid,
invalid o error.
Banco
El widget no mandasuccess cuando guarda la clave. Se queda en
“estamos leyendo tus cuentas” hasta que el banco contesta.
- El banco aceptó y hay cuentas: el widget las muestra y ahí manda
successcon elcred_…. Tu backend recibeconnection.active. - La clave es inválida: el error queda en el widget, el usuario puede
corregirla, y no hay
success. Tu backend recibeconnection.requires_action. - El usuario cierra antes:
exit. Eso no confirma la conexión. Si el banco igual acepta la clave, llegaconnection.active.
VALID no es la confirmación. La
confirmación es connection.active, cuando el banco ya listó las cuentas.
Los movimientos no vienen en ese aviso. Cuando la cartola está sincronizada
se leen como documentos tipo 100:
GET /api/v2/documents/?master_entity_id={empresa}&dte_type__code__in=100.
Responde 2xx al webhook y procesa después. Puede llegarte dos veces.
Para ver o cortar conexiones usa
GET /connections/ y
DELETE /connections/{connection_id}/,
que la deja inactive y suelta la clave.






