A connector step calls a pre-defined third-party action — Slack, Stripe, a custom HTTP API — using the workspace's own stored credentials. The step itself only maps your data into the request; auth, the URL, and the HTTP method all come from the connector definition, not the step config.

This article is about the step, not the connector model

For how connectors are defined by the platform, adopted by an org, and credentialed per workspace, see Automation → Connectors. This article covers using an already-adopted connector inside a logic block.

Config shape

json 
{
  "type": "connector",
  "outputAs": "slackPost",
  "config": {
    "connectorId": "slack",
    "actionId": "post-message",
    "required": true,
    "fieldMappings": [
      { "field": "channel", "value": "#alerts" },
      { "field": "text",    "value": "{{s1.summary}}" }
    ]
  }
}
  • `connectorId` / `actionId` — which connector and which of its actions to call.
  • `fieldMappings` — {field, value} pairs, one per field the action's body_schema declares. value can be a literal or a {{...}} template.
  • `required` (default true) — see below.

required: true vs false

If the workspace hasn't configured this connector, or has it disabled, a required: true step fails the whole run (400/403). Set required: false for an optional integration — an unconfigured or disabled connector then makes the step return { skipped: true } and execution continues.

Where auth comes from

Nothing in the step config configures auth — it's entirely driven by the connector definition's auth_type and the tenant's saved, encrypted credential:

  • `bearer` — Authorization: Bearer <credential.token>
  • `basic` — Authorization: Basic <base64(username:password)>
  • `api_key` — a header named by the credential's header_name, valued from api_key
  • `none` (default if unset) — no auth headers sent

The connector's url_template can also reference the credential directly with {{credential.<key>}} — e.g. a per-account subdomain baked into the URL — resolved from the decrypted credential, not from step config or {{...}} step-output templates.

Request & response

  • Body is built from fieldMappings matched against the action's declared field list, JSON-encoded by default (some connectors, e.g. Stripe-style APIs, use form-encoding — that's set on the connector definition, not the step).
  • Every outbound URL is checked: HTTPS only, no private IPs/localhost, must match the connector's own allowed_domains, and must match the org's connector allowlist if one is configured (Settings → Integrations).
  • Result: { status, headers, body } — body is JSON-parsed automatically when the response's content-type is JSON, otherwise left as text. Reference it as {{slackPost.status}} / {{slackPost.body}}.

Reading a failure

  • 400 — bad/unresolvable URL, or the connector isn't configured for this workspace (required: true).
  • 403 — the resolved host isn't on the connector's or org's allowed-domains list, or the connector is disabled for this workspace.
  • 500 — the connector definition isn't embedded in this API — re-save the logic block in API Studio to refresh it.
  • 502 — the upstream call itself failed: a network error, or the upstream responded with status ≥ 400.
  • 504 — the call didn't complete within the step timeout.

Builder UI

The Connector picker only lists connectors the org admin has adopted (Org Settings → Integrations) — a connector must be adopted before it can be used in any logic block. The Action picker is filtered to actions usable from a logic block. Field Mappings are generated from the selected action's declared fields; each one accepts a literal value or a {{step.field}} reference via the variable picker. Credentials are never entered here — the panel's own help text points to the tenant settings entity, matching "each workspace supplies its own credentials" from the connector model.

Connectors (the full model)

Platform definition → org adoption → tenant credentials.

Step types

Where connector fits among every other step.