An integration is a project-scoped record that stores credentials and configuration for a single external service. Integrations let workflows send notifications, store artifacts, and call external services without embedding secrets in the workflow definition.

The model

Each integration has:

• A provider — a free-form string identifying the service (e.g. slack, s3, openai). The provider is immutable after creation.
• A name — a human-readable label. The (provider, name) pair must be unique within a project.
• Credentials — sensitive secrets such as API keys and tokens. Stored encrypted at rest and never returned by the API.
• Config — non-sensitive provider-specific settings, such as a default S3 bucket name or a sender email address.
• A status — active, inactive, or expired.

Integrations are project-scoped. Copy an integration to another project in the same org using the copy endpoint; the full config blob is cloned without re-entering credentials.

Connecting Slack

curl -sX POST "$MOBIUS_API_URL/v1/projects/my-project/integrations" \
  -H "Authorization: Bearer $MOBIUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "primary",
    "provider": "slack",
    "credentials": { "bot_token": "xoxb-..." },
    "config": { "default_channel": "#ops" }
  }'

Mobius stores the credentials blob encrypted at rest. Subsequent reads of this integration omit the credentials field entirely.

Lifecycle

Where you see it

• Dashboard — Projects → <project> → Integrations lists the supported providers (Slack, Email, Twilio SMS, S3) with a Connected or Not configured badge for each.
• API — the Integrations tag group covers list, create, get, update, delete, and copy operations.

See also

• Actions — steps that use integration-backed providers.
• Workflows — the definition that contains integration-backed steps.
• Runs — the execution context in which integrations are invoked.
• API reference — Integrations — full request and response schemas.