Integrations
Integration catalog
The integration catalog is the project-specific list of providers Mobius can use. Check it before you add provider-backed actions, triggers, or model credentials.
The catalog is runtime data, not a hand-maintained list. Mobius builds it from the project's connection state plus the provider, action, and event registries. Slack and Telegram can also back agent messaging, where inbound provider messages route directly to an agent session.
| 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 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 |
| Clay | clay | api_key | Yes | No |
| 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 |
| Mistral | mistral | api_key | Yes | 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 |
| Stripe | stripe | 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 Govern > 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 platform
mobius catalog get-action slack.message.post --project platform
mobius catalog list-events --project platformThe 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 a provider
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.
- Check wire-format names in the event catalog.