Integrations

Built-in providers

These providers have dedicated executors, OAuth or API key authentication, and config validation. They are available on both self-hosted installs and S6S Cloud.

For any service not listed above, you can always use the http action to call its REST API directly.

How actions are resolved

When you deploy, S6S resolves each step's action in this order:

1. Built-in action name (http, slack, gmail, …)    → used as is
2. Sub-action of a built-in (gmail.send_message,
   google_sheets.append_row, telegram.send_photo)  → rewritten to the built-in
3. Integration stored in the database              → seeded or learned earlier
4. Learning from the provider's API docs           → [Cloud]
5. Learning from model knowledge (no docs found)   → [Cloud]

Steps 1–3 work everywhere. Sub-actions exist for gmail, google_sheets, google_drive, telegram, twitter, discord, imap, youtube and buffer. A new install already stores a set of seeded integrations (for example notion, stripe, hubspot and github). Steps 4–5 are S6S Cloud features. If a provider.action does not resolve, the step cannot run: the deploy fails, or saves it with an UNRESOLVED_INTEGRATION warning. Use a built-in action or http instead.

Examples

A built-in action. Slack needs channel and textTemplate. The credential "default" uses any connected Slack account (see Credentials).

{
  "ref": "notify_team",
  "action": "slack",
  "config": {
    "channel": "#alerts",
    "textTemplate": "New order from {{trigger.output.body.customer}}"
  },
  "credential": "default"
}

A sub-action in provider.action form. S6S rewrites google_sheets.append_row to the built-in google_sheets action with config.action set to append_row.

{
  "ref": "log_order",
  "action": "google_sheets.append_row",
  "config": {
    "spreadsheetId": "your-spreadsheet-id",
    "range": "Orders!A:C",
    "values": [["{{trigger.output.body.order_id}}", "{{trigger.output.body.customer}}", "{{run.startedAt}}"]]
  },
  "credential": "default"
}

A stored integration works the same way. For "action": "notion.create_page", S6S builds the HTTP call from the stored endpoint. Config keys that match the stored body schema (here parent, properties and children) go into the request body. Config keys also fill placeholders in the endpoint URL, such as {database_id} for notion.query_database.

Output shape

Built-in actions return their own output (for example google_sheets append returns updatedRows and updatedRange). The output_shape field of GET /api/v1/integrations/{action} describes each one. Stored and learned integrations run as HTTP calls and return the HTTP envelope, where status is the numeric HTTP status:

{
  "status": 200,
  "statusCode": 200,
  "statusText": "OK",
  "body": { "id": "abc123" }
}

Reference fields with {{step_ref.output.body.field}} in downstream steps. See the Expressions guide for details.

Discovery endpoints

On S6S Cloud, unknown provider.action pairs are learned at deploy time. When a deploy references a provider S6S hasn't seen before:

1. S6S looks for the platform's API documentation on the web.
2. An LLM extracts endpoints, auth configuration, and request body schemas.
3. The result is stored in the database — later deploys resolve it without learning again.
4. After 30 days, the next deploy that uses it re-learns it from fresh docs.

One deploy learns at most 3 new providers.

Confidence scoring

Every learned integration gets a confidence score based on how it was learned.

When a call to a stored integration fails with a 401, 404 or 410, or the response mentions deprecation, S6S flags that provider. On S6S Cloud, the next deploy that uses it re-learns it from fresh docs.