Conexiones

El catálogo de conectores

Crea conexiones desde la página de Conexiones del panel, limitadas a tu entorno.

Autenticación con referencias secret://

Las credenciales nunca viven en el panel en texto claro. En lugar de una contraseña guardas una referencia secret://, y el agent resuelve el valor real en el momento de la ejecución usando su propia identidad ambiental — nunca una clave por conexión incrustada en la configuración. Una referencia puede ser un campo entero o ir embebida a mitad de una cadena:

secret://env/DB_PASSWORD
secret://aws-sm/prod/orders-db?key=password
secret://azure-kv/my-vault/orders-db
secret://gcp-sm/my-project/orders-db

• secret://env/NAME — una variable de entorno en el host del agent (vía su cadena llavero → env).
• secret://aws-sm/… y secret://aws-ps/… — AWS Secrets Manager y SSM Parameter Store.
• secret://azure-kv/… — Azure Key Vault.
• secret://gcp-sm/… — GCP Secret Manager.

Ejemplos prácticos

Una API REST. Crea una conexión de tipo HTTP API, define la URL base (p. ej. https://api.internal.example.com/v1) y elige la autenticación que usa tu API — None para un endpoint abierto, o un bearer token / API key almacenado como una referencia secret://. Deja Allow private networks desactivado para un endpoint público; actívalo para alcanzar una API en tu red interna. Las funciones construidas sobre ella usan entonces rutas relativas como /products o /products/{'{{'}id{'}}'}.

Una base de datos en el host del agent. Crea una conexión PostgreSQL que apunte a donde el agent alcanza la base de datos — para una base de datos que se ejecuta en el mismo host que el agent, eso es el host 127.0.0.1, el puerto 5432, más el nombre de la base de datos, el usuario y la contraseña. Desactiva Require SSL solo si la base de datos no tiene TLS, y activa Allow private networks para que el agent pueda marcar una dirección privada/de loopback. La contraseña se almacena cifrada (o como una referencia secret://) y solo se resuelve en el agent en el momento de la llamada.

Como es el agent — no el backend — quien marca la conexión, el host que introduzcas debe ser resoluble desde la red del agent, no desde ConnXL.

Conectar Supabase

Supabase aloja Postgres estándar, así que el conector Supabase habla el protocolo de Postgres directamente con la base de datos de tu proyecto. Dos cosas difieren de un Postgres autoalojado:

• Host y usuario. Para una conexión directa usa db.<project-ref>.supabase.co, puerto 5432, usuario postgres. Si pasas por el pooler de conexiones de Supabase, el usuario pasa a ser postgres.<project-ref> y el puerto 6543 — el pooler es la opción correcta cuando muchas réplicas del agent comparten un proyecto.
• Modo SSL. Supabase exige TLS pero su CA no está en los almacenes de confianza estándar, así que el conector usa require por defecto (cifrado, certificado sin verificar). Si instalas el certificado CA de Supabase en el host del agent puedes subirlo a verify-full.

La contraseña de la base de datos está en tu panel de Supabase en Project Settings → Database; guárdala como una referencia secret:// igual que cualquier otra credencial.

Para llegar al mismo proyecto a través de la API REST de Supabase, con Row-Level Security aplicada por usuario de Excel con la sesión iniciada, consulta Seguridad a nivel de fila (intercambio de token).

Probar una conexión

Usa Test connection en el panel para comprobar que una fuente es alcanzable. El sondeo se ejecuta en el agent, desde dentro de tu red — una petición HTTP, un SELECT 1 de SQL o un escaneo de caché. El backend nunca marca a tus fuentes de datos por sí mismo, así que esto funciona para fuentes que no son alcanzables desde la internet pública. Las familias de fuentes sin un sondeo en vivo informan "guardada sin probar" en lugar de fallar.

Puedes gestionar las conexiones desde la página de Conexiones de tu complemento una vez que se ha seleccionado un complemento.