The connector step

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.

Config shape

{
  "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 input_schema declares. value can be a literal or a {{...}} template.
• `required` (default true) — see below.
• `entityRef` (optional) — the id of the record this call is about, usually a template such as {{cart.id}}. Use it with a payment checkout: the provider sends the result back later, and this id is how that result finds your record.

required: true vs false

If the workspace hasn't configured this connector (no credentials saved for it), a required: true step fails the whole run (400). Set required: false for an optional integration — a connector the workspace hasn't configured then makes the step return { skipped: true } and execution continues. There is no separate on/off switch: removing a workspace's credentials is how it stops using a connector. The step looks the connector up when the block runs, so nothing about it is stored with the block and it always runs the connector's current definition.

Payment checkouts and other multi-call actions

A connector action can be one request (Slack, a webhook) or several in a row (a PayPal, Stripe, Paddle or Dodo checkout creates the order, then returns the page to send the customer to). Both work in a logic block. A multi-call action returns the values it declares instead of the raw response, plus the provider's full response as raw: for a checkout, {{pay.checkout_url}}, {{pay.order_id}} and {{pay.raw}}.

A checkout only starts the payment. For PayPal the customer approving it does not move the money: add a step that calls the connector's Capture order action once the customer has approved (the order id comes from the provider's notification), or let the connector's webhook settings do it. Which actions a logic block can use is listed in the action picker.

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 reference two different sources: {{credential.<key>}} — e.g. a per-account subdomain baked into the URL — resolves from the decrypted credential; any other {{name}} resolves from the step's own fieldMappings (e.g. Salesforce's Update Record action templates {{sobject_type}}/{{record_id}} straight into its URL path, sourced from the same mapped fields that build the body).

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).
• If the connector action declares a body_wrapper (some providers require the mapped fields nested one level under a specific key, e.g. "properties"), the mapped body is nested under that key before sending — matches the provider's actual API shape without the step author doing anything extra.
• 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 for a single request: { 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, the connector isn't configured for this workspace (required: true), or your organization hasn't enabled this connector.
• 403 — the resolved host isn't on the connector's or org's allowed-domains list.
• 404 — the connector or action doesn't exist, or isn't available to logic blocks.
• 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 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.