Build
Integrations
An integration connects another service to one Mobius project. Connect Slack to post messages, GitHub to react to repository events, or a model provider to use your own account.
Connect a provider
- Open Library > Integrations in the project that should use the account.
- Choose the provider.
- Complete its sign-in, API key, app-install, or account-selection flow.
- Return to the provider page and confirm the connection is ready.
Connections are project-specific. Reconnecting an account or rotating its key does not require editing the agents or loops that use its actions.
A connection can make several things available:
- Actions that an agent or loop can call.
- Events that can start or resume a loop.
- Pickers for channels, repositories, documents, and other provider data.
- AI models billed through the connected account.
- Activity records for diagnosing missing events or failed calls.
Not every provider offers every capability. Open its detail page to see what is
ready in the current project. The mobius CLI cannot connect providers yet;
use the app or API.
Slack and Telegram can also back agent messaging, where incoming messages go directly to an agent conversation.
Browse the catalog
The integration catalog is the project-specific list of providers Mobius can use. Mobius builds it from the project's connection state plus the provider, action, and event registries.
| Catalog source | Contributes |
|---|---|
| Provider registry | Provider metadata, auth kind, and connect mode. |
| Action registry | Action names, schemas, readiness, and usage. |
| Event registry | Provider event names and payload schemas. |
| Project integrations | Connection readiness and credential source. |
Read the live app catalog before assuming a provider is ready. A deployment can enable or hide a provider, and a project can use either Mobius-managed platform credentials or its own connected credentials.
Google providers share a few credential rules. Start with Google integrations when you are connecting a Google provider.
Provider types
| Type | How it works | Use when |
|---|---|---|
| Connected provider | The project stores the provider credential. | You need provider actions or events to run with your account. |
| Built-in provider | Mobius supplies the credential and marks the provider ready without a project-local row. | The provider is read-only or platform-funded and your own quota is not required. |
| Action-only provider | Actions exist, but the provider does not implement the managed connect flow yet. | Create an integration row directly until the provider gets a first-class connect screen. |
| Model provider | The integration stores a model API key for agents, not an action catalog. | You want agents to use your model account instead of the default model route. |
| MCP server | The integration points to a remote Model Context Protocol (MCP) server. | You already operate an MCP server and want its tools available inside Mobius. |
When in doubt, use the provider catalog in the app. It shows the exact readiness and credential source for the current project.
Current providers
| Provider | Provider ID | Auth kind | Actions | Events |
|---|---|---|---|---|
| Anthropic | anthropic | api_key | No | No |
| Apollo.io | apollo | api_key | Yes | No |
| Bitbucket Cloud | bitbucket_cloud | oauth2_user | Yes | Yes |
| Discord | discord | api_key | Yes | No |
| Firecrawl | firecrawl | api_key | Yes | No |
| Gmail | gmail | oauth2_user | Yes | Yes |
| GitHub | github | github_app_install | Yes | Yes |
| Google Ads | google_ads | oauth2_user | Yes | No |
| Google Calendar | google_calendar | oauth2_user | Yes | Yes |
| Google Gemini | gemini | api_key | No | No |
| Google Drive | google_drive | oauth2_user | No | Yes |
| Google Places | google_places | api_key | Yes | No |
| Google Sheets | google_sheets | oauth2_user | Yes | No |
| HubSpot | hubspot | oauth2_user | Yes | Yes |
| Jira | jira | api_key | Yes | Yes |
| Linear | linear | api_key | Yes | Yes |
| MCP server | mcp | api_key | Dynamic | No |
| Notion | notion | oauth2_user | Yes | Yes |
| OpenAI | openai | api_key | No | No |
| OpenRouter | openrouter | api_key | No | No |
| Polymarket | polymarket | none | Yes | No |
| ScrapeCreators | scrapecreators | api_key | Yes | No |
| SendGrid | sendgrid | api_key | Yes | No |
| Slack | slack | oauth2_user | Yes | Yes |
| Telegram | telegram | api_key | Yes | Yes |
| Twilio SMS | twilio | api_key | Yes | No |
| X | x | api_key | Yes | Yes |
| xAI Grok | xai | api_key | No | No |
Some providers appear only when the deployment has the backing service configured. The catalog endpoint is the final source of truth for the project you are using.
Inspect the catalog
From the app
Open Library > Integrations to see provider readiness and connection state. Provider detail pages show available actions, source events, webhook endpoints, and recent provider events.
Open Library > Actions when you need input schemas, output schemas, action annotations, or direct invocation.
From the CLI
The mobius CLI can inspect the action and event catalogs:
mobius catalog list-actions --project ridgeline
mobius catalog get-action slack.message.post --project ridgeline
mobius catalog list-events --project ridgelineThe CLI does not connect integrations yet. Use the app or HTTP API for connection setup.
From the API
Use the provider catalog endpoint when you are building your own admin surface or authoring tool. Use the action and event catalog endpoints when that tool needs exact names and schemas. The CLI commands above call those same catalog endpoints.
Connect through the API
Most providers use a generic connect endpoint under
/v1/projects/{project}/integrations/providers/{provider}/connect. Redirect
providers return a redirect_url; inline providers return an integration row.
Provider pages list the body shape and endpoint to use, and the API reference
has the exact schema.
Action-only providers use POST /v1/projects/{project}/integrations until they
have a managed connect endpoint.
Actions and events
Provider actions run inside Mobius and use the resolved credential source for the project. A ready project-owned integration wins over a platform credential. If an action posts, deletes, merges, sends, or mutates upstream state, retries can repeat that side effect. Use idempotency fields where the provider supports them, or add an interaction before irreversible steps.
Provider events enter Mobius as integration events. Mobius then turns them into
source events that event triggers and wait_for_event steps can match.
Use exact event names for narrow loops. Use a trailing wildcard only when every event under a prefix should start or resume the run.
triggers:
- kind: event
config:
event_type: github.pull_request.openedNext
- Use provider credentials from integrations.
- Call provider actions from steps.
- Match provider events with triggers.
- Receive outside changes with source events.
- Send Mobius events to your software with webhooks.
- Check wire-format names in the event catalog.