Add a warehouse connection
A connector tells Monomer which warehouse to use and which warehouse identity to use there. Give it a recognizable name, such as Analytics production.
Prepare the source
Section titled “Prepare the source”Ask your warehouse administrator for an endpoint reachable from Monomer, the database or catalog to use, and a dedicated read-only warehouse account allowed to read the needed tables and metadata. A read-only account is required. Your laptop’s localhost does not identify a warehouse reachable from Monomer’s server. Use the TLS settings required by your administrator.
Monomer does not guarantee read-only access. If the connection account has write permissions, Explorers and their Agents can modify warehouse data. Native SQL checks help prevent common mistakes; they do not replace warehouse permissions.
Do not grant this account permission to execute procedures, use pass-through queries, or invoke remote/external functions. Review these permissions for each warehouse: PostgreSQL and Redshift procedures, functions, and external connections; BigQuery procedures, remote functions, and connection access such as EXTERNAL_QUERY; Trino procedures and pass-through table functions such as system.query; Snowflake procedures, external functions, and integrations; and Databricks procedures, external functions, and connections. Have the warehouse administrator review direct and inherited privileges using the vendor’s access controls. Monomer does not inspect the side effects of these functions. Catalog selection limits browsing and modeling, not the data reachable by SQL.
You need permission to manage connectors in the workspace. Enter credentials directly in the connector form. Do not put them in an agent prompt, document, connector name, or support message.
Create the connector
Section titled “Create the connector”- Select your workspace and open Sources → Connectors.
- Select Create connector, choose the source type, and select Next.
- Enter a display name and fill the source settings and credential method below, then select Create. Use values from your administrator; examples such as port numbers are not credentials.
- Catalog opens with the Choose tables to load panel for the new connector. For a source with a catalog level, choose catalogs first and select Continue.
- Wait for the list of schemas. This first listing is the connection check: on success the panel says Connected and how many schemas it found.
- Choose tables and select Save and refresh, as described in Select and refresh Catalog. Then run a small SQL query to confirm access to the intended data.
There is no separate connection test. If the first listing fails, the panel names the cause, such as a rejected sign-in or an unreachable host, and nothing is saved to Catalog. Owners can select Replace credentials or Edit settings there and return to the same panel after saving; others are asked to contact a workspace Owner. Select Try again after the fix.
| Source | Required settings | Credential choices | Optional settings |
|---|---|---|---|
| PostgreSQL | Host, Port, Database | Username and password | Schema, SSL mode |
| BigQuery | Project ID, Location | Service account JSON | — |
| Snowflake | Account, Warehouse, Database | Username and password; username and private key | Schema, Role; private key passphrase |
| Databricks | Host, Warehouse ID | Access token; OAuth client ID and secret | Catalog, Schema |
| Trino | Host, Port, Catalog | Username and password | Schema, SSL, SSL verification |
| Redshift | Host, Port, Database | Username and password; IAM | Schema, SSL mode |
For Redshift IAM, provide AWS access key ID, AWS secret access key, AWS region, cluster ID, and database user. For Databricks, provide the SQL warehouse ID and workspace host. Monomer accepts 1–128 alphanumeric characters for the ID; this is Monomer’s input restriction, not a vendor format guarantee. Cluster HTTP paths are not supported. For BigQuery, provide the complete service account JSON and the location in which your data is queried. These values must belong to the same source environment.
Discover the Workspace, read workspace, and follow its availableOperations to list workspace/connectors. Send the advertised CONNECTOR_CREATE entry to monomer_describe before constructing the input. These monomer_create inputs show the source-specific envelopes. Replace the illustrative workspace ID and source settings with discovered values. All credential values below are placeholders: supply real credentials through an approved secure input flow, never by copying them into a conversation. Use the connector schema for other source types.
For PostgreSQL, connection settings belong in properties and the username/password pair belongs in credential:
monomer_create input
{ "workspaceId": "0198ef28-2000-7000-8000-000000000001", "path": "workspace/connectors", "input": { "kind": "CONNECTOR_CREATE", "connectorType": "POSTGRESQL", "displayName": "Analytics PostgreSQL", "properties": {"host": "warehouse.example.com", "port": 5432, "database": "analytics", "schema": "analytics", "sslMode": "VERIFY_FULL"}, "credential": {"kind": "USERNAME_PASSWORD", "username": "REPLACE_WITH_USERNAME", "password": "REPLACE_WITH_PASSWORD"} }}For BigQuery, call monomer_create with projectId and location. serviceAccountJson is a string containing the complete JSON credential, not a nested object; the placeholder below is not a usable credential.
monomer_create input
{ "workspaceId": "0198ef28-2000-7000-8000-000000000001", "path": "workspace/connectors", "input": { "kind": "CONNECTOR_CREATE", "connectorType": "BIGQUERY", "displayName": "Analytics BigQuery", "properties": {"projectId": "example-analytics", "location": "US"}, "credential": {"kind": "SERVICE_ACCOUNT_JSON", "serviceAccountJson": "REPLACE_WITH_COMPLETE_SERVICE_ACCOUNT_JSON_STRING"} }}Read the returned connector path to confirm the saved non-secret settings. Then select Catalog scopes and refresh; successful creation alone does not verify warehouse access.
Correct settings or replace credentials
Section titled “Correct settings or replace credentials”Open the connector details and use its settings or credential replacement action. Settings and credentials are changed separately. A replacement credential must contain all fields for the chosen method; existing secret values are never displayed. PostgreSQL and Redshift database names are fixed when created, so create a separate connector if you need another database.
An agent reads the connector, follows its advertised edit or credential replacement entry, and calls monomer_describe with that entry before constructing the call. Read result.path after the change to confirm its non-secret settings.
After a change, repeat the refresh or query that failed. If access still fails, share the connector name, source type, visible error, and request reference with your administrator, without sharing secret values.
Delete a connector
Section titled “Delete a connector”Workspace Owners can delete a connector from its details. Type the connector’s name to confirm. The dialog lists the semantic models that read its tables; they won’t run until they use another connector.
Deleting removes the connector’s tables from Catalog and destroys its saved credentials. Explore runs and refresh history stay and show it as “Deleted connector”. A deleted connector no longer counts toward the workspace’s connector limit, and its name can be reused. Deletion can’t be undone.
If a Catalog refresh is running for the connector, cancel it in Catalog, then delete. Agents with the Owner role follow the connector read’s advertised delete entry and call monomer_invoke with that exact path and action, omitting input.