Configurar un Conector de Datos generalmente significa leer la documentación de API y completar cada campo manualmente. Con Operator, describe lo que Fin necesita buscar o actualizar, y Operator redacta un nuevo conector o repara uno que no funciona. Use este artículo para aprender qué puede configurar Operator, cómo revisar y probar sus propuestas, y las limitaciones a tener en cuenta.

Cada cambio llega como una propuesta. Usted la revisa, aprueba cada llamada de prueba y elige si publicarla o guardarla como borrador. Operator no puede cambiar un conector ni llamar a una API por sí solo.

Nota: Operator está incluido con el complemento Pro. Para chatear con Operator necesita el permiso Can access Fin Operator. Para aplicar un cambio en el conector también necesita el permiso Fin AI Agent & Automation y Can access Developer Hub.

Si es nuevo en Conectores de Datos, comience con Cómo configurar Conectores de Datos.

Cómo construir o reparar un Conector de Datos con Operator

Todo el proceso ocurre en un chat de Operator, desde la primera solicitud hasta el conector publicado.

Paso 1: Pida a Operator

En un chat de Operator, describa lo que Fin necesita. Por ejemplo:

“Cree un conector que busque un pedido de Shopify por su número.”
“Fin sigue diciendo que no puede encontrar el pedido. ¿Puedes reparar el conector Get Order?”

Paso 2: Operator investiga

Antes de proponer algo, Operator puede buscar información en su espacio de trabajo:

Busque sus conectores y lea la configuración completa de cada uno.
Lea la respuesta de prueba guardada o la respuesta simulada de un conector.
Vea qué workflows, procedimientos y macros usan un conector.
Revise las tasas de éxito recientes y el historial de ejecuciones. Ve el estado y el tiempo, no lo que se envió o recibió.
Liste los atributos que puede usar en la solicitud o como objetivos de mapeo.
Liste sus tokens de autenticación por nombre y tipo. Nunca ve el secreto.

Paso 3: Revise la propuesta

La propuesta aparece en el chat como una tarjeta Conector de datos.

El encabezado muestra el nombre del conector y una insignia Nuevo, En vivo, Borrador o Pausado. Un cambio de nombre muestra el nombre antiguo tachado.
API muestra el método, URL, entradas de datos, encabezados, carga útil, prueba y tokens de autenticación.
Datos muestra los campos de respuesta, código Python y mapeos de objetos.
Fin muestra el prompt que Fin lee y la audiencia.
Seguridad muestra la configuración de autenticación del cliente.
Para una edición, la tarjeta muestra los cambios respecto a la versión en vivo. Las secciones sin cambios comienzan colapsadas, y cada sección muestra cuántas líneas se añadieron y eliminaron.
Los tokens de autenticación se muestran solo por nombre.

Paso 4: Apruebe la prueba

Antes de ejecutar una prueba, Operator muestra una tarjeta titulada Probar “nombre del conector” con los valores que enviará.

Revise los valores. No se envía nada hasta que haga clic en Ejecutar prueba. Cancelar la detiene.
La prueba llama a la API real. El resultado aparece como, por ejemplo, “Prueba aprobada (HTTP 200)” o “Prueba fallida (HTTP 401)”.
Operator lee la respuesta y la usa para configurar los campos de respuesta.

Operator también puede hacerle a Fin una pregunta de prueba en una conversación previa, como lo haría un cliente. Esto muestra si Fin selecciona el conector y cómo usa la respuesta. En una vista previa, Fin responde como si los cambios pendientes del conector ya se hubieran aplicado, y usa la respuesta de prueba guardada o simulada en lugar de llamar a la API.

Importante: Las pruebas envían solicitudes reales al sistema conectado. Si un conector crea, actualiza o elimina datos, probarlo realiza ese cambio. Use registros de prueba. Operator pide su aprobación antes de cada prueba.

Paso 5: Aplique el cambio

Usted elige cómo se aplica el cambio:

En un conector en vivo, el botón principal es Publicar. Guardar como borrador (o Actualizar borrador, si existe un borrador) está en el menú.
En un conector nuevo, borrador o pausado, el botón principal es Guardar como borrador (o Actualizar borrador). Publicar está en el menú.
Publicar pregunta “¿Listo para publicar?” primero. Permanece deshabilitado hasta que la prueba de Operator haya pasado, a menos que el conector use una respuesta simulada. Una edición que no cambia la solicitud (URL, método, encabezados, cuerpo, entradas y tokens de autenticación) mantiene la prueba aprobada anterior del conector.
Una eliminación muestra un botón rojo Eliminar y una advertencia de que no se puede deshacer.
El icono de la papelera (Descartar cambio) elimina la propuesta.
Aplicar todo aplica todos los cambios en el chat. Un conector nuevo se guarda como borrador, y una edición mantiene su estado actual en vivo o borrador.

Si alguien editó el conector mientras la propuesta estaba pendiente, la tarjeta dice “Este cambio se basa en una versión desactualizada” y al aplicar pregunta “¿Aplicar sobre cambios más recientes?”. Las ediciones más recientes se sobrescriben solo si hace clic en Aplicar de todos modos.

Paso 6: Después de aplicar

Aparece un mensaje “Cambios aplicados con éxito” y el chat registra “Aplicó 1 cambio” con el conector marcado como Publicado o Borrador. Haga clic en el nombre del conector para abrir su página de configuración. Cada cambio aplicado también aparece en el registro de actividad del equipo como “Propuesta de Operator aplicada”.

Un cambio publicado funciona como cualquier conector construido a mano, y Fin comienza a usarlo en conversaciones de inmediato. Un borrador no afecta las conversaciones hasta que se publique. Los clientes nunca ven a Operator ni sus propuestas.

Qué puede configurar Operator

Nombre y descripción — Los compañeros ven la descripción en la configuración del conector.
La solicitud — URL, método, encabezados y cuerpo. La URL debe ser HTTPS.
Entradas de datos — Los valores que Fin recopila del cliente, como un número de pedido. Cada entrada tiene un nombre, tipo y descripción, se marca como obligatoria u opcional, y puede tener un valor predeterminado.
Tokens de autenticación — Operator puede adjuntar o separar tokens existentes. Cada token se envía como su propio encabezado.
Campos de respuesta — Construidos a partir de una respuesta de prueba o una respuesta simulada. Deciden qué campos ve Fin, cómo se llama cada uno, su formato y cómo se traducen los valores codificados en palabras. Un bloque de código Python puede remodelar la respuesta en su lugar.
Una respuesta simulada — Un cuerpo de respuesta de ejemplo, usado para construir los campos de respuesta antes de que se pueda probar la API.
Mapeos de objetos — Escriba valores de respuesta en atributos de conversación, usuario u objeto personalizado.
Cómo lo usa Fin — Si Fin puede seleccionar el conector por sí solo, el prompt que Fin lee para decidir cuándo usarlo, si Fin puede escribir a través de él y una audiencia construida a partir de segmentos.
Verificación del cliente — Si Fin llama al conector solo para clientes que han pasado la verificación de identidad.

Consejo: Operator pone atributos de Intercom, como el correo electrónico del cliente, directamente en la solicitud en lugar de agregarlos como entradas de datos. Esa es la configuración recomendada. Cada entrada de datos que Operator añade es un valor que Fin recopila del cliente.

Limitaciones conocidas

Créditos de Operator — Los chats de Operator usan créditos de Operator como cualquier otro trabajo de Operator.
Usted aplica cada cambio — Operator no puede publicar, guardar ni eliminar un conector por sí mismo.
Las pruebas envían solicitudes reales — Si un conector crea, actualiza o elimina datos, probarlo realiza ese cambio en el sistema conectado. Use registros de prueba.
Tokens — Operator no puede ver los valores de los tokens de autenticación, ni puede crear, editar o eliminar tokens. Agregue un nuevo token en la configuración de Autenticación, luego pida a Operator que lo adjunte. Mantenga las claves API en tokens, no en la URL o el cuerpo, donde Operator puede leerlas.
Aplicar reemplaza las ediciones de borrador no publicadas — Operator construye su cambio sobre la versión en vivo. Aplicarlo, ya sea con Publicar o Guardar como borrador, reemplaza cualquier edición de borrador hecha en el editor desde entonces. Publique o descarte primero sus propias ediciones de borrador.
Los conectores en vivo no se pueden eliminar — Operator solo puede eliminar conectores en borrador o pausados. Para eliminar un conector en vivo, primero páuselo en su configuración. Operator no puede pausar, reanudar, duplicar o archivar conectores, ni revertir a una versión anterior.
Conectores MCP — Operator no puede editar, probar ni eliminar conectores que provienen de un servidor MCP. Adminístrelos en la configuración del servidor MCP.
No hay plantillas — Operator no puede instalar un conector desde una plantilla.
Tipos de entrada — Operator no puede agregar valores de entrada estáticos, ni tipos de entrada de lista u objeto.
Versiones — Los cambios de conector de Operator se aplican directamente al conector. No pueden añadirse a una Fin Release.
Vista previa de Fin — Cuando Operator le hace a Fin una pregunta de prueba, Fin usa la respuesta de prueba guardada o simulada en lugar de llamar a la API. Las eliminaciones pendientes no se previsualizan, y un cambio sin respuesta de prueba o simulada no tiene nada que devolver.

Si un conector falla en conversaciones después de publicarse, consulte Comprender errores de Conectores de Datos.

Preguntas frecuentes

¿Por qué está deshabilitado el botón Publicar?

No hay una prueba aprobada en la última versión del cambio. Cambiar la URL, método, encabezados, cuerpo, entradas o tokens de autenticación borra una prueba anterior. Pida a Operator que ejecute una prueba o use una respuesta simulada. Guardar como borrador siempre funciona.

¿Por qué una prueba falla con 401 cuando el conector funciona en conversaciones?

Las pruebas no llevan identidad de usuario final, por lo que los conectores que verifican quién es el cliente no pueden aprobar una prueba. Los tokens de tipo USER envían su valor de prueba estático en su lugar.

¿Qué puede ver Operator en mi conector?

Operator nunca ve los valores de los tokens de autenticación. Ve la URL, el cuerpo y el bloque de código completo, igual que muestra Developer Hub, y solo los primeros cuatro caracteres de los valores de encabezado. En las respuestas de prueba, cualquier token o credencial que la API devuelva está enmascarado.

Construya y repare Conectores de Datos con Operator