Documentation by ClonePartner

Start typing to search.

Core Concepts

Connectors and slots

View Markdown

Learn how typed connector slots in tasks are bound to stored Connector configurations at job creation or run time.

Connectors and slots

Two halves of one idea

A slot is a task's declaration that it needs a connector of some type. It is a name and a type, nothing more:

connectors:
  source:
    type: csv
  destination:
    type: sqlite

A Connector is a stored, named configuration for that type — the directory, connection string, or credentials — created on the Connectors page or in a CLI connectors.yaml. Server-stored Connector configurations are encrypted at rest with the deployment's encryption key.

Slots keep tasks portable; Connectors keep credentials in exactly one place. The two meet at binding time.

flowchart LR S["Task slot: destination (sqlite)"] --> B{Binding} B -->|Job connector_mapping| C[(Stored Connector: prod-db)] B -->|Run Now dialog| C B -->|CLI connectors.yaml| F[connectors.yaml entry]
Slot binding

The three binding paths

Through a Job. A Job Template's task nodes map each task slot name to a template-level connector name, and creating a Job binds each template name to a stored Connector ID. This is the normal production path: bind once, run many times. The Create Job dialog filters each select to Connectors of the slot's declared type.

Standalone run. Running a task directly — Run Now in the UI or a run created via the API — binds stored Connectors to the task's slots for that single run.

CLI. The CLI reads a connectors.yaml file whose entry names match the task's slot names (or, for envoy job run, the template's connector names). Values support ${ENV_VAR} placeholders, resolved from the environment only for the connectors the run actually uses.

In every path, the type is enforced: binding a csv Connector to a sqlite slot fails.

Resolution: what the task actually receives

Whichever path bound them, the runner inlines the full connector configurations into the resolved task YAML handed to the run subprocess. The task never fetches credentials itself and cannot tell where they came from — which is precisely why the same YAML works in all three paths.

Connector types

Every Connector has a type that determines its config schema and its callable methods (read, find, upsert, execute, …), which tasks invoke through call_method steps. Types come from two places:

  • Built-in types, compiled into the binary: sqlite, csv, yaml, azure-blob, s3, truto, mongodb, mysql, postgres, mssql, dynamics365, jira, freshdesk, and others depending on the build.
  • Catalog types, registered at boot from the deployment's catalog — API connectors such as zendesk, hubspot, salesforce, slack, or stripe, backed by connected accounts. See Catalog and connected accounts.

The Connector reference documents each type's config fields and methods.

Beyond task pipelines

Bound Connectors power more than runs: Data Explorer browses and queries any stored Connector interactively, and connectors with upload capability accept files through the UI. The operator's guide to creating and testing Connectors is Managing connectors.