Reusable connections

A connection holds credentials for a provider on the org — separate from any one data source, and org-scoped: edisyl connections list shows every connection the organization has, not just the ones a particular pack can query.

When to use one

Reach for a connection instead of data-sources create when:

• One account, several databases. A Snowflake account with a dozen databases only needs its credentials stored once; each database becomes its own data source (and its own pack) mounted on top.
• The provider isn’t SQL. API providers like linear have no database to mount at all — they only ever exist as a connection, attached straight to a pack.

Create and mount

1. Test the credentials. Same connector-specific config JSON as data-sources test-connection, just a different command:

   edisyl connections test --provider postgres --config-file db.json

2. Create the connection.

   edisyl connections create --name "Snowflake prod" --provider snowflake --config-file sf.json

   For an API provider (Linear today), pipe the token instead of passing a config file, and attach it to a pack right away with --pack-id:

   printf '%s' "$LINEAR_API_KEY" | edisyl connections create \
     --provider linear --name "Linear" --pack-id <pack-id> --token-stdin

   Tip

   Use --token-stdin: it exists so a token never lands in shell history or a process listing.

3. See what a SQL connection can reach.

   edisyl connections databases <connection-id>

4. Mount a database as a data source. --type/--config are skipped entirely — --connection-id reuses the stored credentials, and this path mounts directly onto the connection without creating a new one:

   edisyl data-sources create --name "Analytics" --connection-id <connection-id> --database ANALYTICS

Attaching an existing connection to another pack

edisyl connections attach <connection-id> --pack-id <pack-id> is the API-provider equivalent of mounting a data source — it’s how the same Linear connection ends up available to a second pack without creating it twice.

Org targeting

Every data-sources and connections subcommand defaults to the authenticated profile’s org. --org-id <uuid> overrides it where an override actually makes sense — it isn’t registered on data-sources list (org-scoped by the auth token already) or on test-connection/connections test (validating an unsaved config, tied to no org yet).