Aloja OpenConnector con Docker

Inicia el entorno de ejecución

Necesitas Git y Docker con Docker Compose. Empieza con una acción sin autenticación antes de configurar una cuenta de aplicación. Clona el repositorio e inicia su imagen publicada. Mantén esta prueba local en tu propio equipo.

git clone https://github.com/oomol-lab/open-connector.git
cd open-connector
docker compose up

Ejecuta tu primera acción

En otra terminal, obtén las principales noticias de Hacker News. Esta acción de solo lectura no requiere una cuenta del proveedor.

curl -s -X POST \
  http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Ejecuta esta acción de solo lectura y sin autenticación en un entorno de ejecución local. Añade tu token Bearer del entorno de ejecución si la autenticación está habilitada.

Conecta una cuenta

Abre la consola local, selecciona un proveedor y configura sus credenciales. Los proveedores OAuth requieren una aplicación OAuth que registres en ese servicio.

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.

Antes de exponer públicamente un entorno de ejecución, configura la autenticación de administración, los tokens del entorno, el cifrado de credenciales y el origen público de OAuth. Sigue la guía de despliegue para la configuración de producción.

Antes de exponer un despliegue

El archivo Compose del proyecto monta connector-data en /app/data. Configura valores distintos para OOMOL_CONNECT_ADMIN_TOKEN y OOMOL_CONNECT_RUNTIME_TOKEN, además de OOMOL_CONNECT_ENCRYPTION_KEY, antes de permitir el acceso remoto. Establece el origen público y configura la terminación HTTPS en el punto de entrada de tu despliegue. Mantén los secretos fuera del control de versiones.

Planifica las actualizaciones y la recuperación

Registra la versión de la imagen que despliegues y haz una copia de seguridad de la base de datos del entorno junto con una copia de su clave de cifrado almacenada de forma segura. Prueba la restauración en un entorno aislado antes de actualizar. Perder la clave hace irrecuperables los registros cifrados; eliminar el volumen de datos elimina la base de datos local.

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.