Create connection
Create a data connection to an external source (e.g. Postgres, Snowflake).
Call GET /v1/connections/data/types/{type} first: it lists the exact
config and secrets keys this type accepts, which are required, and a
ready-to-send example. Validation messages name a field by its UI label
(“Database is required”); that listing is what maps the label back to the key
to send (pg_db).
config holds non-secret settings; credentials go in secrets and
are stored server-side, never returned. A new connection reports status
ACTIVE and lastTestStatus empty: status ACTIVE means the record
exists, NOT that credentials work. Call the connection test endpoint to
verify — it sets lastTestStatus to PASS/FAIL and stamps
lastTestedAt. Check lastTestStatus == PASS before relying on a
connection, and attach datasets before expecting any data to be analyzable.
For an HTTP/REST connection only, configure durable incremental requests in
connector-level snapshot_config.http_replication. Do not place advanced
replication settings in config or in a dataset’s snapshot settings. The
request schema documents the supported limits, resources, cursors,
pagination modes, and a complete example.
Authorizations
The access token received from the authorization server in the OAuth 2.0 flow.
Body
Connection name, shown across Summation.
Source type, e.g. POSTGRES or SNOWFLAKE.
Optional human-readable description.
Non-secret, type-specific settings. The accepted keys differ per type — GET /v1/connections/data/types/{type} lists them with which are required and a ready-to-send example. Postgres, for instance, takes pg_host, pg_port, pg_db, pg_user and pg_sslmode.
Credentials, keyed the same way as config — see GET /v1/connections/data/types/{type} for the secret keys of a given type (Postgres: pg_pass). Stored server-side as secret refs; never returned by any response.
Connector-level snapshot policy. Only HTTP/REST connections may set snapshot_config.http_replication; never put http_replication in connector config or dataset snapshot settings. The object accepts version=1, validate_server_address (optional; true is the only accepted value — server-address validation cannot be disabled through this API), connector-scoped limits, and resources. Each resource defines request_path; cursor, required for every INCREMENTAL_* sync strategy and optional for FULL_REFRESH, in formats RFC3339, STRING, or INTEGER; optional composite tie-breaker and DESTINATION_MAX or EXPLICIT bootstrap; pagination modes NEXT_LINK and TOKEN using JSON pointers, LINK_HEADER using the RFC 8288 Link response header, or KEYSET and OFFSET using query parameters (KEYSET requires a cursor); initial_query_parameters, which require a cursor; query_parameters containing ${cursor} and, for a composite cursor, ${tie_breaker}. A cursor-less resource rejects both placeholders, and may set constant query_parameters only under TOKEN or OFFSET pagination, where they are sent on every page; NEXT_LINK and LINK_HEADER follow a provider-built continuation URL and so reject query_parameters entirely. Optional source-to-destination field_mappings, tombstone, and execution_order. Data Management validates the complete configuration. Encode integers above 2^53-1 as strings (INTEGER-format cursor values are parsed back losslessly). PATCH semantics: a present snapshot_config replaces the stored policy, with one protection — on HTTP connections, omitting the http_replication key preserves the stored http_replication, so clients that do not round-trip it cannot erase it. Include http_replication to replace it, or set it to null to clear it. Omit the snapshot_config field entirely to leave the whole policy unchanged.
Response
Successful Response