# Connectors and slots

> Source: https://docs.clonepartner.com/concepts/connectors-and-slots/

<!-- sources: references/envoy/connectors.md, src/config-parser.ts, src/connectors/index.ts, src/server/runner/manager.ts, references/envoy/jobs.md -->

# 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:

```yaml
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.

```mermaid Slot binding
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]
```

## 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](/connectors/catalog-and-connected-accounts/).

The [Connector reference](/connectors/) documents each type's config fields and methods.

## Beyond task pipelines

Bound Connectors power more than runs: [Data Explorer](/using/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](/using/connectors/).

## Related

- [Tasks, jobs, and templates](/concepts/tasks-jobs-and-templates/) — where binding fits in the three-layer model
- [Managing connectors](/using/connectors/) — creating, testing, and uploading files to Connectors
- [connectors.yaml reference](/cli/connectors-yaml/) — the CLI binding file
- [Connector reference](/connectors/) — every type, config field, and method