Integraciones operativas

Relvo es el sistema de registro de tus ingresos, pero no emite documentos tributarios por sí solo ni mueve dinero por sí solo. Para eso se conecta con sistemas externos: el proveedor de facturación electrónica, el banco, la pasarela de cobro y tus propios sistemas.

Cada conexión es un objeto explícito con credenciales, estado y bitácora. Nada queda «conectado implícitamente».

Facturación electrónica

En Chile el documento tributario lo emite el SII a través de un proveedor autorizado. Relvo prepara el documento, lo envía por el proveedor conectado y guarda la respuesta de la autoridad.

Cada conexión fiscal declara su ambiente: sandbox o producción. No es una etiqueta de presentación — es un límite de seguridad. Los documentos de un ambiente nunca se mezclan con los del otro, ni al consultar ni al emitir.

!

La autoridad manda sobre el documento, no sobre tu contrato

Si el SII rechaza un documento, la factura queda en estado fiscal rejected y hay que corregir y reenviar. Si queda pending, ya fue enviada: reenviarla puede generar un segundo documento con folio propio. El camino correcto es reconciliar con el proveedor. Ver los cuatro ejes de una factura.

Sincronización fiscal

Además de emitir, Relvo puede leer desde el SII lo que tu empresa emitió: documentos hechos en otro sistema, antes de Relvo o en paralelo. Eso alimenta la cartera de cobranza y la conciliación con documentos que Relvo no calculó.

Los documentos así importados quedan marcados con su origen. Es lo que permite distinguir, en cualquier reporte, lo que Relvo calculó de lo que Relvo sólo registró — y por eso puede aparecer un cliente que nadie creó a mano, marcado para revisión.

Bancos y movimientos

Conecta las cuentas bancarias cuyos movimientos quieres traer a Relvo. La validación de credenciales y el MFA ocurren dentro de un widget del proveedor: las claves bancarias nunca pasan por el frontend de Relvo ni se guardan en Relvo.

Una vez conectada la cuenta, se mapea a una cuenta contable y sus movimientos alimentan la conciliación. Si no hay conexión disponible, la otra vía es cargar cartolas — el resultado en conciliación es el mismo.

Sincronización fiscal y conexión bancariaHaz clic para ampliar

×

Medios de cobro

El medio de cobro de un cliente declara por qué vía se espera el dinero. Hay dos mundos:

Vía	Quién ejecuta el cobro
Transferencia, pago manual, cobro propio	Relvo. No hay sistema externo ni credenciales que conectar.
Pasarela externa	Un proveedor de cobro conectado, que ejecuta el cargo e informa el resultado.

La distinción importa: sólo una vía externa puede quedar desconectada, requerir reconexión o fallar por credenciales. Una transferencia no se «cae».

Estado de una conexión

Una conexión no es sólo «activa o no». Su estado dice qué hacer:

Estado	Qué significa
active	Operando
syncing	Trayendo datos en este momento
auth_failed · requires_reconnect	Credenciales inválidas o expiradas — requiere acción humana
rate_limited	El proveedor está limitando; Relvo reintenta solo
disabled · inactive	Apagada deliberadamente
error	Falla del proveedor, sin acción del usuario pendiente

requires_reconnect es la única de estas que detiene el flujo y no se resuelve sola: alguien tiene que volver a autenticar.

Cómo entran los datos

Vía	Uso típico
API	Tus sistemas envían eventos de consumo o leen documentos
Webhook entrante	El proveedor avisa un cambio (pago recibido, documento aceptado)
Carga de archivo	Cartolas bancarias, consumo histórico, migraciones
Manual	Registro puntual desde la interfaz

Cada ingestión queda registrada como una corrida con su resultado —completa, parcial o fallida— y con el detalle fila por fila. Una carga parcial no se pierde en silencio: las filas que fallaron quedan identificadas para corregir y reprocesar.

API y tokens

Los tokens de la API se emiten desde Desarrolladores y tienen alcances con la forma recurso:acción — por ejemplo usage_events:write, invoices:read, contracts:write. Escribir implica leer sobre el mismo recurso: un token con invoices:write también puede leer facturas.

!

`full_access` casi nunca es el token correcto

full_access pasa cualquier verificación de alcance. Sirve para una prueba rápida, no para un sistema en producción y nunca para un cliente MCP. Emite el alcance más angosto que el integrador necesite: es la diferencia entre una credencial filtrada que lee consumo y una que emite facturas.

Un token se revoca, no se edita. Ver la guía de autenticación y la referencia de la API.

Webhooks salientes

Relvo puede avisar a tus sistemas cuando ocurre algo relevante. Los eventos disponibles son un catálogo cerrado y versionado:

Evento	Cuándo ocurre
invoice.drafted	Se generó un borrador de factura
invoice.issued	Se emitió una factura
invoice.fiscal_rejected	La autoridad rechazó la factura
credit_note.issued · debit_note.issued	Se emitió una nota
credit_note.fiscal_rejected · debit_note.fiscal_rejected	La autoridad rechazó una nota
message.received	Llegó una respuesta de un cliente a un correo de Relvo

Cada endpoint tiene su propio secreto de firma: verifica la firma antes de confiar en el cuerpo del mensaje. Un endpoint recién creado queda pendiente de verificación hasta que responde correctamente, y puede deshabilitarse sin perder su configuración. Ver la guía de webhooks.

Guías de integraciónAutenticación, idempotencia, errores y webhooks, con ejemplos.Servidor MCPConecta un cliente de IA a tus datos de Relvo con alcances acotados.Pagos y conciliaciónQué hace Relvo con los movimientos bancarios que trae.Cobros, prefacturas y facturasLos estados que cambian cuando responde la autoridad tributaria.