Cómo conectar un chatbot de IA a una API REST sin código
Convierta una solicitud en lenguaje natural en un conector REST revisado y luego compruebe que el correo correcto revela solo los campos aprobados mientras que un correo incorrecto no revela nada.
Cuando conecta un chatbot a una API REST, la validación y la salida con privilegios mínimos son tan importantes como enviar la solicitud con éxito.
Un conector de API (API Connector) proporciona al asistente una herramienta con un propósito estrictamente delimitado para leer o modificar datos en vivo. Es diferente de la base de conocimientos: las fuentes indexadas responden a partir de contenido procesado previamente, mientras que un conector envía una nueva solicitud HTTP solo cuando la petición del visitante coincide con las instrucciones de la herramienta.
Este ejemplo para principiantes utiliza la API de prueba pública JSONPlaceholder y no requiere secretos. Una solicitud GET para el ID de cliente 1 devuelve un objeto JSON ficticio. Antes de que el asistente pueda mostrar los campos aprobados de nombre, empresa y sitio web, una regla de validación compara el correo electrónico del visitante con el valor `email` de esa respuesta.
Probará ambas direcciones en conversaciones separadas. `sincere@april.biz` en minúsculas debe coincidir con el valor de la respuesta `Sincere@april.biz` y permitir exactamente Leanne Graham, Romaguera-Crona y hildegard.org. `wrong@example.com` debe devolver solo el mensaje neutral de no coincidencia y no debe exponer ningún dato del cliente.
Trabajar sin código no elimina la responsabilidad de seguridad. El asistente de IA crea un primer borrador; usted aún debe verificar HTTPS, autenticación, acceso con privilegios mínimos, tipos de campos, marcadores de posición, rutas de respuesta, mensajes de error y el comportamiento tanto de autorización como de denegación antes de la activación.
Reproductor en dos clics que protege la privacidad
Cómo conectar un chatbot de IA a una API REST (sin código)
Conecte su chatbot a una API REST sin código. Mapee campos, valide datos, restrinja salidas y pruebe peticiones autorizadas con éxito.
El reproductor de YouTube permanece bloqueado hasta que pulsa Reproducir. Al cargarlo, su navegador se conecta a YouTube y puede transmitir datos técnicos a Google.
Abrir directamente en YouTubeQué obtendrá al final
- Un modelo mental claro sobre cuándo se ejecuta un conector de API
- Un conector generado por IA y revisado campo por campo
- Campos obligatorios de ID de usuario y correo electrónico con validación de respuesta que no distingue entre mayúsculas y minúsculas
- Una consulta real y exitosa en JSONPlaceholder con tres datos explícitamente aprobados
- Un intento independiente bloqueado por correo incorrecto con cero filtración de datos de clientes
- Una lista de verificación reutilizable de seguridad, errores y limpieza para producción
Antes de empezar
- Plan Standard o superior, o un periodo de prueba activo con acceso a API Connectors
- Un asistente que no esté en producción dedicado a este tutorial
- Un endpoint HTTPS documentado y su respuesta JSON esperada
- Registros de prueba no confidenciales; nunca use datos reales de clientes en el tutorial
- Una expectativa documentada de resultado permitido y una de resultado denegado
- Para producción más adelante: una credencial de API dedicada con privilegios mínimos almacenada fuera de los prompts
Recopilar, llamar, validar, responder
El prompt de la herramienta decide cuándo es aplicable el conector. Los campos tipados le indican al asistente qué valores del visitante debe recopilar. Los marcadores de posición como `{user_id}` asignan esos valores a la URL, los encabezados o el cuerpo de la solicitud. La validación de la respuesta compara luego un valor del visitante con una ruta JSON antes de que el modelo reciba un resultado permitido.
En este ejemplo, el asistente recopila `user_id` y `email`, solicita `/users/1`, lee el JSON y aplica `email equals response.email, ignoring case`. Una regla que falla devuelve únicamente su mensaje de error configurado; los datos de la respuesta no deben llegar al visitante.
La API, no el modelo de lenguaje, debe seguir siendo la autoridad para la autenticación y los permisos. Utilice la validación del conector como una protección de presentación adicional, no como un sustituto de la autorización real de la API. El conector debe recibir únicamente el alcance de lectura o escritura requerido para esta única tarea.
01–07
Configuración paso a paso
Abrir API Connectors y definir una sola tarea delimitada
Comience en el asistente de pruebas antes de revisar o agregar una herramienta activa.
Abra el espacio de trabajo del asistente y elija API Connectors. Esta es la lista de herramientas en vivo asignadas únicamente a ese asistente. Una tarjeta existente muestra su estado, método HTTP, endpoint, resumen del prompt y los campos requeridos del visitante; el botón Add API Connector inicia una configuración independiente.
Escriba la tarea en una sola oración antes de seleccionar Add: “Look up one fictional JSONPlaceholder customer after user ID and email verification.” Mantenga los cambios de pedidos, la creación de tickets o cualquier acción de escritura en otro conector con permisos independientes.
Para un primer proyecto, elija una solicitud GET de solo lectura. Las operaciones de lectura son más fáciles de inspeccionar y recuperar que las acciones POST, PATCH o DELETE, pero aun así requieren validación cuando los datos devueltos no deben ser públicos.
Elegir Set up with AI
Describa el resultado esperado en lugar de trasladar la documentación campo por campo.
El cuadro de diálogo ofrece Set up with AI y Set up manually. Elija el asistente de IA cuando tenga un endpoint y un resultado claros; utilice la configuración manual cuando deba copiar con exactitud una configuración ya aprobada.
El asistente puede investigar y rellenar campos, pero usted sigue siendo responsable de revisar el endpoint, el método, los encabezados, los tipos de campos, la validación y el prompt antes de guardar. No pegue secretos de producción en el chat.
Describir la consulta a JSONPlaceholder y revisar los campos generados
El asistente de IA completa un primer borrador exhaustivo e inspeccionable.
Solicite `https://jsonplaceholder.typicode.com/users/{user_id}` con los campos obligatorios `user_id` como Number y `email` como Email. Indique al asistente que valide el correo electrónico comparándolo con la ruta de respuesta `email` sin distinguir entre mayúsculas y minúsculas, y que revele únicamente name, `company.name` y website.
El asistente verificado creó “JSONPlaceholder Customer Lookup”, GET, encabezados vacíos, los dos campos obligatorios y el marcador de posición correcto para el endpoint. JSONPlaceholder contiene registros de demostración ficticios, por lo que el tutorial no expone credenciales ni datos reales de clientes.
Revisar la validación y las instrucciones de la herramienta
Los controles de seguridad deben estar explícitamente definidos antes de pulsar Create.
Confirme que la validación compara el campo de entrada `email` con la ruta de respuesta `email` usando Equals (ignore case). Utilice un mensaje de error neutral: “The email address does not match this customer profile. Please try again.”
El prompt de la herramienta debe indicar cuándo usar el conector, qué campos recopilar y qué campos de la respuesta se pueden presentar. Para entornos de producción, use una credencial dedicada de solo lectura en los encabezados o una gestión de secretos en el servidor, y nunca permita que un cambio generado por IA amplíe los permisos sin supervisión.
Crear y verificar la tarjeta del conector activo
Confirme conjuntamente el método, el endpoint, los campos y el estado activo.
Seleccione Create y vuelva a la lista. La tarjeta activa debe mostrar JSONPlaceholder Customer Lookup, GET, el endpoint, el resumen del prompt, los campos `user_id` y `email`, y el interruptor habilitado.
No continúe con las pruebas en el chat si la tarjeta está inactiva o si el endpoint difiere del formulario revisado. Una configuración guardada todavía no es prueba de que la llamada a la API y la regla de seguridad funcionen.
Probar la consulta de cliente autorizada
Utilice un registro fijo y cambie deliberadamente el uso de mayúsculas en el correo para comprobar la comparación seleccionada.
Abra Test chatbot en una vista previa nueva y pregunte: “Look up demo customer 1. The verification email is sincere@april.biz.” La respuesta de la API contiene `Sincere@april.biz`; el valor en minúsculas ingresado por el visitante se acepta porque la comparación seleccionada no distingue entre mayúsculas y minúsculas. La respuesta debe devolver Leanne Graham, Romaguera-Crona y hildegard.org.
Registre la entrada exacta y la respuesta visible. Esta es la línea base de la ruta de autorización para futuras pruebas de regresión. Un modelo diferente podría redactar el texto de otra manera, pero los tres datos autorizados deben ser correctos y el correo de respuesta, nombre de usuario, teléfono, dirección, coordenadas, ID y JSON sin procesar deben permanecer ocultos.
Comprobar en una conversación nueva que un correo incorrecto queda bloqueado
La prueba de la ruta de denegación es tan importante como el resultado exitoso y no debe heredar la respuesta de la sesión permitida.
Inicie una nueva sesión de chat para que la respuesta anterior sobre Leanne Graham no forme parte del contexto de la conversación. Solicite el cliente 1 con `wrong@example.com`. La prueba es satisfactoria solo cuando el chatbot muestra el mensaje de no coincidencia configurado y no revela ninguno de estos valores: Leanne Graham, Sincere@april.biz, Romaguera-Crona o hildegard.org.
Esto demuestra la validación a nivel de presentación para este tutorial; no convierte a JSONPlaceholder en un servicio de autenticación real. Una API de producción debe autorizar el acceso en el servidor antes de devolver datos protegidos, devolviendo idealmente solo los campos que el asistente tiene permitido mostrar.
Repita la prueba de denegación tras realizar cambios en los campos, las rutas de validación, la estructura de la respuesta del endpoint, el prompt o el modelo. Pruebe también la ausencia de campos, tipos de entrada no válidos, JSON mal formado, tiempos de espera agotados, 401/403, 404 y límites de peticiones. Desactive el conector de inmediato si cualquier fallo expone campos protegidos.
Ejemplo y resultado
Vea la prueba práctica y su resultado
Cada tutorial incluye un caso de entrada definido, el resultado previsto y un registro transparente de las comprobaciones realizadas.
Ejemplo práctico: Conectar un chatbot de IA a una API REST sin código
Este escenario exacto se completó con la cuenta temporal del tutorial.
Entrada exacta de la prueba
Look up demo customer 1 with lowercase sincere@april.biz, then start a fresh chat and repeat with wrong@example.com.
Resultado previsto
El correo coincidente revela únicamente nombre, empresa y sitio web; el correo incorrecto no revela ningún registro de cliente.
Qué se comprobó realmente
El conector real devolvió Leanne Graham, Romaguera-Crona y hildegard.org para la entrada válida. Una sesión independiente de denegación bloqueó wrong@example.com con el mensaje de validación configurado y no expuso ningún dato del cliente.
Consejos útiles
Consiga una configuración fiable
Pruebe con ejemplos realistas, guarde su punto de partida y modifique un solo ajuste cada vez para evaluar las mejoras con claridad.
Utilizar una identidad de API de solo lectura
El chatbot no debe recibir permisos de escritura ni de eliminación cuando solo necesita consultar el estado de un pedido.
Probar respuestas mal formadas
Verifique tiempos de espera agotados, campos faltantes, respuestas distintas de 200 y JSON no válido para que los visitantes reciban una respuesta alternativa segura.
Elegir un modelo con uso confiable de herramientas
Compare los mismos prompts de autorización y denegación en Model Arena. Prefiera el modelo más rápido y económico que recopile de forma coherente todos los campos, llame al conector una sola vez y respete la validación.
Mantener separadas las sesiones de autorización y de denegación
Una sesión de denegación limpia demuestra que la respuesta bloqueada no copió valores de clientes del contexto de una conversación anterior.
Tratar los cambios en conectores como cambios de código
Registre conjuntamente la versión del endpoint, el prompt, los campos, las rutas de validación y los resultados de las pruebas. Exija una revisión antes de ampliar un método, un host o el alcance de los permisos.
Si algo no funciona
Resolución de problemas
Revise el estado, los permisos y los datos de prueba de forma sistemática antes de cambiar el modelo o la instrucción.
El conector devuelve 401 o 403
Verifique el encabezado de autenticación, el alcance del token y los permisos en la API con una credencial de prueba que no sea de producción. Nunca resuelva el problema otorgando un token de administrador amplio.
La validación siempre falla
Inspeccione la respuesta JSON real y confirme la ruta de respuesta, el tipo de valor y el modo de comparación. Los valores anidados como `company.name` requieren la ruta exacta.
El chatbot expone campos no previstos
Desactive el conector inmediatamente, restrinja el prompt de la herramienta y la respuesta de la API, y repita las pruebas de denegación. Prefiera un endpoint en el servidor que devuelva únicamente los campos aprobados.
El asistente responde de memoria en lugar de llamar al conector
Haga que el prompt de la herramienta sea específico sobre la intención y los campos obligatorios, elimine conectores que compitan en el asistente de prueba y comience con una conversación nueva. La respuesta debe coincidir con la respuesta actual de la API, no con un valor visto anteriormente.
La API devuelve 404 para un registro inexistente
Utilice una respuesta neutral de «no encontrado» que no confirme identificadores confidenciales. No intente adivinar identificadores con nuevos intentos y evite que el conector presente un resultado exitoso anterior.
La solicitud agota el tiempo de espera o devuelve un JSON mal formado
Muestre un mensaje alternativo de servicio temporalmente no disponible, registre el fallo técnico fuera de la respuesta al visitante y evite mostrar fragmentos incompletos de la respuesta. Reintente solo siguiendo una política documentada para que la petición de un visitante no provoque una sobrecarga de solicitudes.
Listo para una prueba tipo producción
Revise los registros y los permisos del conector después del lanzamiento. Agregue acciones adicionales solo como conectores independientes y delimitados, con su propia validación.