Skip to main content
Connections are the one area where the contract will actively mislead you: config keys differ between what you send and what you read back, and a connection built from wrong keys is created successfully and reports ACTIVE until you test it. Read this page before writing connector code. Per-connector key names are on the connector pages; the product-side walkthrough is Connectors.

​
Add a data connection

GET /v1/connections/data/types

List the connector types whose config and secrets keys are published, plus undocumented_types for the rest. Read this before creating a connection.

GET /v1/connections/data/types/{connector_type}

Show one connector type’s keys, plus a ready-to-send create example.

POST /v1/connections/data

Create a connection.

POST /v1/connections/data/{connection_id}/tests

Test a connection.

POST /v1/connections/data/{connection_id}/resources

Browse what a connection can see.

POST /v1/connections/data/{connection_id}/datasets

Attach datasets to a connection.
Read the keys; don’t infer them. Config keys are lowercase and prefixed per connector: pg_db for Postgres, snowflake_account for Snowflake. The Form fields table on each connector page lists form labels, not API keys; where a page has an API key column, that is the one to send. Responses render keys in camelCase (pgDb), so reading a key off a GET and sending it straight back will also fail.
Always test immediately after create. A config object accepts unknown keys, so a connection built from the wrong key names is created and reports ACTIVE. Nothing goes wrong until test, and the error names the form label rather than the key it wanted.
Connection names become secret-store keys: use kebab-case, since spaces are rejected with a validation error that doesn’t explain itself.
The types listing returns two sets. types are the connector types whose keys are published; the detail route gives you those plus a ready-to-send example. undocumented_types are types the product supports whose keys are not published yet; their detail route returns not_documented and points you at the app. A type listed there is supported, but without published key names you would be guessing at fields, so create it in the app once; everything about it works over the API afterwards.

​
Manage a connection

GET /v1/connections/data

List connections.

GET /v1/connections/data/{connection_id}

Show a connection.

PATCH /v1/connections/data/{connection_id}

Update a connection.

DELETE /v1/connections/data/{connection_id}

Delete a connection.

POST /v1/connections/data/{connection_id}/tests

Re-test a connection’s credentials and reachability at any time.

​
Datasets and refresh

GET /v1/connections/data/{connection_id}/datasets

List a connection’s datasets.

GET /v1/connections/data/{connection_id}/snapshots

List snapshot runs.

PATCH /v1/connections/data/{connection_id}/datasets/{dataset_id}

Rename a dataset or change its description.

DELETE /v1/connections/data/{connection_id}/datasets/{dataset_id}

Detach a dataset from the connection, leaving the source table in place. Requires confirm=true.

POST /v1/connections/data/{connection_id}/datasets/{dataset_id}/snapshots

Snapshot a dataset now.

​
Connect an app

GET /v1/connections/app/catalog

List available app connectors.

GET /v1/connections/app

List connected apps.

GET /v1/connections/app/catalog/{app_key}/tools

List what an app connector can do.

GET /v1/connections/app/{connection_id}

Show a connected app.

PATCH /v1/connections/app/{connection_id}

Update a connected app.

POST /v1/connections/app/{connection_id}/disconnect

Disconnect an app, keeping its connection record.

DELETE /v1/connections/app/{connection_id}

Delete an app connection.