DOCUMENTACIÓN
Credenciales, tokens del entorno de ejecución y OAuth de OpenConnector
Configura credenciales de proveedores, acceso al entorno de ejecución, callbacks OAuth y conexiones con nombre en un entorno OpenConnector de alojamiento propio.
Código revisado el 2026-09-09. Estos ejemplos se contrastaron con la revisión del código enlazada. No implican una verificación de la API en vivo; tu versión desplegada puede ser diferente.
Acceso al entorno de ejecución y credenciales del proveedor
Las credenciales de administración protegen la consola y los endpoints /api. Los tokens del entorno de ejecución autorizan a los clientes /v1 y /mcp. Las credenciales del proveedor pertenecen a la cuenta conectada y permanecen dentro del entorno; estas credenciales no son intercambiables.
Registra tu aplicación OAuth
Para el alojamiento propio, registra una aplicación OAuth con el proveedor y copia el valor exacto de expectedRedirectUri de /api/oauth/configs. Establece OOMOL_CONNECT_ORIGIN con el origen público antes de configurar un callback remoto. Autoriza solo los ámbitos que necesite tu flujo de trabajo.
Elige la conexión de la cuenta
Una llamada sin alias usa la conexión predeterminada del proveedor. Selecciona una conexión con nombre mediante x-oo-connector-alias. Las concesiones de conexión del token del entorno de ejecución pueden restringir las cuentas que un cliente puede usar.
Conserva y protege las credenciales
La imagen Docker usa /app/data para los datos del entorno local. Mantén estos datos en un volumen persistente. Configura OOMOL_CONNECT_ENCRYPTION_KEY para las credenciales almacenadas y conserva la clave para la recuperación; consulta la guía de despliegue antes de exponer el entorno.
Completa la conexión OAuth
- Primero establece OOMOL_CONNECT_ORIGIN con la dirección que usa tu navegador. Consulta /api/oauth/configs y copia exactamente el expectedRedirectUri del proveedor en tu aplicación OAuth. Añade tu token Bearer de administración si la autenticación de administración está habilitada.
- En la consola local, guarda el ID de cliente y el secreto OAuth del proveedor. Elige un subconjunto de los ámbitos declarados por el proveedor si es necesario, inicia la autorización y aprueba el acceso en el flujo del proveedor en el navegador.
- Tras el callback, inspecciona /api/connections. Confirma la identidad de la cuenta y el nombre de la conexión antes de invocar una acción. Una conexión con nombre debe existir previamente; seleccionar un alias no la crea.
La primera solicitud de abajo inspecciona las cuentas configuradas con el token de administración. La segunda invoca una acción de solo lectura con el token del entorno de ejecución y una conexión existente llamada work. Sustituye el nombre de la conexión por el tuyo; omite la cabecera de alias para usar la conexión predeterminada.
curl -s http://localhost:3000/api/connections \
-H "Authorization: Bearer $OOMOL_CONNECT_ADMIN_TOKEN"curl -s -X POST \
http://localhost:3000/v1/actions/github.get_current_user \
-H "Authorization: Bearer $OOMOL_CONNECT_RUNTIME_TOKEN" \
-H 'x-oo-connector-alias: work' \
-H 'content-type: application/json' \
-d '{"input":{}}'Lee el resultado
Las respuestas HTTP del entorno usan success, message, data y meta. Inspecciona success y el esquema de salida de la acción, no solo el estado HTTP. Cuando los metadatos de ejecución incluyan executionId, úsalo para localizar el registro correspondiente con datos sensibles ocultos. El ejemplo siguiente ilustra la estructura de la respuesta; no es un resultado de la API en vivo.
{
"success": true,
"message": "OK",
"data": {},
"meta": {}
}Si falla la llamada
- Si falla la autenticación, comprueba el endpoint y el tipo de credencial: el acceso de administración protege /api; un token Bearer del entorno autoriza /v1 y /mcp. Una clave de API del proveedor no es un token del entorno de ejecución.
- Si se deniega un permiso, comprueba los ámbitos requeridos por la acción, las reglas de acciones del entorno y las concesiones de conexión. Un token válido puede seguir sin tener permiso para usar la cuenta seleccionada.
- Si faltan resultados o están vacíos, confirma la cuenta conectada y su acceso al recurso solicitado. Una autorización exitosa no concede acceso a todos los espacios de trabajo, canales o documentos.
- Inspecciona el error y el registro de ejecución antes de reintentar. Si una acción modifica datos del proveedor, comprueba si ya terminó; no repitas la solicitud a ciegas.