Bsale × Lelemon
La PyME chilena emitiendo DTEs
desde un solo agente IA.

Es absurdo que cada vendor construya su propio agente IA.

La PyME chilena promedio usa Bsale para facturar, Khipu para cobrar, un banco vía Fintoc, un CRM, un ERP, una pasarela de envíos. Si cada uno de esos vendors construye su propio agente IA, el dueño termina con 8 chatbots diferentes, cada uno con su login y su forma de hablar. Nadie quiere eso.

La forma sensata: UN agente, en el canal donde la PyME ya vive (WhatsApp), que se conecta a todos los proveedores que el comercio ya usa. Las integraciones se manejan de forma central y segura — el dueño solo conversa.

El protocolo abierto que hace eso posible es Model Context Protocol (MCP), el estándar de Anthropic que ya soportan Claude, Cursor, ChatGPT y la mayoría de los frameworks de agentes. Cuando un comercio le pide a un agente "emite una factura por 50.000 a Acme SpA", el modelo no inventa la respuesta: invoca un tool MCP real que ejecuta la operación contra Bsale.

Connector multi-tenant Bsale, ya en código.

Construí mcify — un framework open source (Apache 2.0) en TypeScript para exponer APIs como servidores MCP — y dentro del repo está el connector de Bsale como ejemplo canónico de la integración multi-tenant.

Lo que un agente puede invocar hoy

Una infraestructura. Muchos comercios.

El connector es multi-tenant desde el día uno: un único servidor mcify atiende a N comercios distintos. Cada comercio aporta su access_token de Bsale en el onboarding; el servidor lo guarda asociado a un bearer token único, y desde ese momento todas las llamadas de ese comercio se autentican con el bearer (jamás con el access_token directo).

        Comercio A         Comercio B         Comercio C
            |                  |                  |
     access_token A    access_token B    access_token C
            |                  |                  |
            v                  v                  v
        +-------------------------------------------+
        |   bsale-mcp.lelemon.cloud (UN deploy)     |
        |   ┌───────────────────────────────────┐   |
        |   │  Session Store                    │   |
        |   │  bearer_X → { orgId: "A",         │   |
        |   │              bsaleAccessToken }   │   |
        |   │  bearer_Y → { orgId: "B", ... }   │   |
        |   └───────────────────────────────────┘   |
        +-------------------------------------------+
                          |
            +-------------+-------------+
            |             |             |
       Claude A       Claude B       Claude C
       Bearer X       Bearer Y       Bearer Z

Flujo end-to-end (un request real)

1. El usuario habla con Claude:

   "Emite una factura electrónica para Acme SpA, RUT 11.111.111-1, por 50.000 CLP."

2. Claude decide qué tool llamar.

   Identifica que necesita bsale_emit_dte y construye los argumentos.

3. Claude invoca el tool vía mcify:

   POST https://bsale-mcp.lelemon.cloud/mcp con bearer del comercio. El servidor valida el bearer en la base, resuelve el access_token de Bsale del comercio, construye la llamada a api.bsale.io/v1/documents.json.

4. Bsale emite el DTE

   y devuelve el folio + las URLs del PDF/XML al servidor mcify.

5. Claude responde al usuario:

   "Factura folio 1234 emitida. PDF: bsale.io/pdf/...". El usuario recibe la URL.

El comercio nunca ve el access_token. El agente nunca recibe el access_token. La credencial vive solo en el servidor, indexada por bearer y resuelta por request.

El access_token nunca sale del servidor.

• Aislamiento por bearer. Cada comercio tiene su token único. Ningún comercio puede acceder a datos de otro, ni siquiera con un agente malicioso.
• Nunca en inputs. El connector no acepta orgId ni credenciales como parámetros — el servidor los resuelve desde el bearer validado. Esto previene el antipatrón más común en multi-tenant.
• Revocación instantánea. Un comando del operador (admin.mjs revoke <bearer>) bloquea al comercio en el siguiente request. Sin redeploy.
• Rate limits y timeouts por tool. 30 emisiones/min, 240 lecturas/min, timeouts de 5–15s. Los DTE tienen un rate limit más bajo porque tienen peso legal.
• 19 tests automatizados, lint estricto, type-safe end-to-end con Zod. CI verde en cada commit.

Bsale como pilar del ecosistema. Lelemon como operador.

La idea no es que Bsale construya un agente más. Es que Bsale forme parte de el agente — el que las PyMEs chilenas ya usan en WhatsApp para operar todas sus herramientas digitales desde un mismo lugar.

Lelemon opera la infraestructura: el connector open source, el servicio multi-tenant, el onboarding de cada comercio, la integración con WhatsApp, el modelo de IA. Bsale aporta lo que ya hace mejor que nadie en Chile: la facturación electrónica.

Este mismo modelo escala: Khipu ya tiene su connector, Fintoc también, y cada vendor que se sume es una pieza más del agente único que la PyME chilena maneja desde WhatsApp. Bsale puede ser el primer partner formal.

Estudio digital chileno · IA aplicada para PyMEs.