La API de Eva y lo que se construye a la medida

Primera capacidad: conversar. Mandas un mensaje al agente y recibes su respuesta, en una llamada normal o en streaming si quieres mostrar la respuesta mientras se escribe. Es la misma máquina que atiende tus canales, expuesta para tu propia aplicación.

Segunda: leer la conversación. Puedes consultar el historial de un hilo y la lista de eventos de ese hilo, que es la forma sencilla de mantener sincronizada tu interfaz sin montar infraestructura de tiempo real.

Tercera: recibir eventos. Cada agente puede tener un webhook de salida firmado, con marca de tiempo y firma HMAC-SHA256 en los encabezados, para que verifiques que el evento salió de nosotros y no de alguien más. Si prefieres no exponer un endpoint, la alternativa por defecto es consultar los eventos tú.

Cuarta: mandar una plantilla aprobada de WhatsApp desde tus sistemas. Es la que usa un ERP o un core de facturación cuando quiere avisar algo fuera de la ventana de conversación: un pedido listo, una factura timbrada, un pago aplicado. La plantilla la aprueba Meta; nosotros la disparamos.

Dos detalles que conviene saber antes de escribir código. Las llaves son por agente, no por cuenta: una llave resuelve a un agente y solo a ese. Y esta superficie no crece a CRM, catálogo, facturación ni administración: si necesitas eso, la respuesta no es la API pública, son los primitivos de la siguiente sección.

Conexión a tu API. Se configura una URL base sobre HTTPS con autenticación sin credenciales, por token bearer o por llave de API. La validación de URL rechaza destinos inseguros o de red privada, y eso no es negociable ni siquiera cuando el cliente insiste.

Acciones sobre tus registros. Se definen llamadas tipadas de tipo GET, POST, PUT, PATCH o DELETE contra tu API, atadas a un registro de Eva, auditadas cada vez que corren, y disponibles como botón o como automatización en una etapa del CRM. Es lo que convierte «mover la tarjeta a Cerrado» en «crear el pedido en tu sistema».

Eventos hacia afuera. El proveedor genérico de webhook manda los eventos canónicos del CRM a tu endpoint, con llave de API o token bearer si tu lado lo pide. El mismo mecanismo sirve para tu sistema propio o para un endpoint de una herramienta de automatización, pero eso es configuración a la medida, no un conector con nombre.

Catálogo servido por tu API. Un catálogo puede tener como fuente tu endpoint en vez de un archivo: se configura el acceso, se resincroniza solo cada veinticuatro horas por defecto y puedes forzar una resincronización cuando lo necesites. Es la ruta correcta cuando tu inventario vive en tu ERP y no lo vas a exportar a mano cada semana.

Herramientas HTTP por agente. Además de todo lo anterior, un agente puede tener herramientas propias que llaman a tus endpoints con encabezados, parámetros, plantillas de cuerpo y autenticación. Eso es lo que le permite consultar tu sistema en media conversación y contestar con el dato tuyo, no con uno inventado.

Y aquí va la parte que casi nadie escribe: sistemas como CONTPAQi, Mercado Libre o tu ERP se conectan a la medida sobre estos primitivos durante la implementación — no existen como conectores de un click, y quien te prometa lo contrario te está vendiendo humo.

Casi siempre es la misma forma: catálogo por API, acciones y webhooks. Empieza por el catálogo, porque es lo que decide si el agente cotiza con tus precios o se los inventa. Tu sistema expone un endpoint con productos, precios y existencias; Eva lo toma como fuente del catálogo y lo resincroniza a diario, y para el dato que tiene que ser exacto en el momento se agrega una herramienta HTTP que consulta en vivo.

Sigue el lado de las acciones. Se define qué puede escribir Eva en tu sistema y desde dónde: un botón en la etapa del CRM que crea el pedido, otro que consulta el estado de un envío, otro que registra el pago. Cada acción es explícita y queda auditada; nada escribe en tu ERP porque el modelo lo consideró buena idea.

Cierra el circuito con los eventos. Los eventos del CRM salen por webhook hacia tus sistemas, y tu core manda plantillas aprobadas de WhatsApp por la API pública cuando pasa algo de tu lado. Ahí ya no hay dos mundos: la conversación en WhatsApp, Instagram, Messenger, llamadas, correo y sitio, más comentarios de Instagram y de anuncios de TikTok, y tu sistema hablando el mismo idioma.

El orden importa porque el riesgo no está repartido parejo. El catálogo y las herramientas de lectura se prueban rápido y se corrigen sin dolor; las acciones que escriben en tu sistema se prueban con datos de prueba y se abren al final.

Pídenos la clasificación de cada sistema que mencionaste, en tres cubetas y sin adornos: nativo hoy, a la medida sobre los primitivos, o no se puede. Si alguien te da una lista donde todo cae en la primera cubeta, no estás leyendo un alcance, estás leyendo una carta de ventas.

Pídenos por escrito qué necesita tu lado para que lo a la medida sea posible: documentación de tu API, quién autoriza las credenciales, si hay ambiente de pruebas, si el endpoint es alcanzable por HTTPS desde fuera y qué pasa cuando tu sistema está caído. Sin eso, cualquier estimación es adivinanza.

Pídenos que te digamos qué NO vamos a hacer. Es la parte del alcance que más se ahorra la gente y la que más caro sale después.

Y pídenos ver el primitivo funcionando, no una lámina. Una acción real contra un endpoint de prueba tuyo vale más que cualquier catálogo de logos, incluido el nuestro.

• Trae la documentación de tu API antes de la primera junta técnica.
• Define quién de tu lado autoriza credenciales y ambiente de pruebas.
• Confirma que tu endpoint es alcanzable por HTTPS desde fuera de tu red.
• Empieza por el catálogo y por las lecturas; deja las escrituras para el final.
• Enumera las acciones que Eva podrá ejecutar, una por una, y quién las autoriza.
• Decide si recibes eventos por webhook o si prefieres consultarlos.
• Guarda una llave por agente y trátala como credencial, no como configuración.
• Pide la clasificación de cada sistema en nativo, a la medida o no se puede.