> ## Documentation Index > Fetch the complete documentation index at: https://docs.summation.com/llms.txt > Use this file to discover all available pages before exploring further. # Connections > Create, test, and browse data and app connections over the API, including the key names that trip people up. 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](/features/connectors#supported-data-sources); the product-side walkthrough is [Connectors](/features/connectors). ## Add a data connection List the connector types whose `config` and `secrets` keys are published, plus `undocumented_types` for the rest. Read this before creating a connection. Show one connector type's keys, plus a ready-to-send create example. Create a connection. Test a connection. Browse what a connection can see. 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. * **A `not_documented` response is about the key names, not the capability.** Creation validates against the connector's real field set, so an undocumented type can pass type validation and fail on a *field* error instead. A field error means the type was accepted. * **Validation errors name UI labels, not keys.** Map the label back through the type listing. * **`sumcli connections list` can return `{"connections": []}` when connections exist.** The CLI reads `data.connections`; the API returns them under `data.connectors`. If the list looks empty but the user says they created one, check `GET /v1/connections/data` before telling them otherwise. * **Attaching datasets is not enough to make data usable.** They deploy at tenant level but are not in the project until you also `catalog attach` each table. Skip it and the analyst sees nothing, which surfaces much later as an inexplicably empty report. Check with `catalog list`; it must be non-empty. * **Browse with no prefix first, then use the paths it returns.** The prefix shape is source-specific (a schema name alone for Postgres, a longer path elsewhere), and a prefix that matches nothing comes back as an empty result with `ok: true`, which is indistinguishable from a source with no tables. * **Name each dataset as you attach it.** `--name` is only accepted alongside a single `--from-source`, and there is no rename afterwards, so a batch attach leaves permanent auto-generated names. * **Browsing won't show columns.** They're only visible once a dataset is attached, so choosing what to attach is done on table names alone. * **On sources that fold case** (Snowflake and friends), the same path can expose both `PERSONS` and `persons` as different tables. Unquoted SQL folds to uppercase, so an existing analysis usually means the uppercase one. This does not apply to Postgres. ## Manage a connection List connections. Show a connection. Update a connection. Delete a connection. Re-test a connection's credentials and reachability at any time. ## Datasets and refresh List a connection's datasets. List snapshot runs. Rename a dataset or change its description. Detach a dataset from the connection, leaving the source table in place. Requires `confirm=true`. Snapshot a dataset now. ## Connect an app List available app connectors. List connected apps. List what an app connector can do. Show a connected app. Update a connected app. Disconnect an app, keeping its connection record. Delete an app connection.