Reference
Integrations
An integration is an account you connect to a project so Mobius can use it. Connect Slack and your agents can post to Slack. Connect Google Workspace and they can read mail, check calendars, and write to spreadsheets.
Connecting one is the sign-in flow you already know: click the provider, sign in, approve the permissions, done. Mobius holds the connection so you never paste a password into a job.
Your jobs and agents refer to what they want to do, not to the credential. When you reconnect an account or rotate a key, nothing that uses it needs editing.
Connecting one
- Open Library > Integrations.
- Pick the provider.
- Complete its sign-in, API key, app install, or account selection.
- Come back to the integration page and confirm it says connected.
The catalog separates three groups: providers you've connected, providers that work without any setup, and providers that still need you to do something. A logo means Mobius supports it; the connection state tells you whether this project can use it right now.
Each provider has its own page in the integration catalog with the exact steps, what becomes available, and what to do when it goes wrong.
Connections are per-project. If you run one project per client, you connect each client's Slack in their own project, which is exactly what you want.
What you get from a connection
Depending on the provider, connecting can give you:
- Actions your jobs and agents can call.
- Events that start jobs when something happens over there.
- Pickers in the editor for channels, repositories, documents, and so on, so you're choosing from a list rather than pasting an ID.
- AI models backed by that account.
- Recent activity, which is where you look when something isn't arriving.
Not every provider does all of these. The provider's page says what to expect.
When the provider isn't in the catalog
Your PSA, RMM, documentation platform, or backup console probably isn't here yet. This is the most common question we get, and the answer is that it's usually a solvable afternoon.
Most of these platforms can do two things, and those two things are all you need:
Getting work into Mobius. If the platform can call a URL when something happens, point it at an HTTP trigger. A ticket is created, your PSA calls the URL, your job starts with the ticket's details.
If it can't call a URL but it can send email, point a notification at an agent's email address instead. Less elegant, works fine.
Getting Mobius to act on it. If the platform has an API, create a custom HTTP action under Library > Actions. From then on it behaves like any other action.
For anything that has to stay inside your network, a worker is the third option.
Integration or secret?
Use an integration when Mobius knows the provider. The connect flow asks for exactly the right thing and the actions appear on their own.
Use a secret for your own worker code, or for a provider Mobius doesn't model yet.
Quick test: if it's under Library > Integrations, use the integration. Otherwise put the credential in a secret and call it from your own action.
Use the pickers
When the editor offers you a picker for a channel, repository, team, or document, use it rather than pasting an ID.
The picker checks the connected account as you choose, which catches a stale name or a missing permission right there, instead of at 3am when the job runs.
When an event doesn't arrive
Check the integration's recent activity first, before touching anything else.
If Mobius never received the event, the problem is on the provider's side: the app isn't installed, a webhook isn't configured, or the account is missing a permission. If the event did arrive, the problem is your trigger's event name or its condition.
That order matters. Editing a trigger cannot fix an event that was never sent, and people lose hours to that. Source events walks the whole path.
Rotating credentials
Reconnect or rotate from the provider's detail page. Everything that uses the integration keeps working, because jobs and agents refer to capability names, not to the credential itself.
Warning: Never paste a provider key into a job's inputs or a step's fields. Those values show up in run history, which plenty of people can read. Use an integration or a secret.
Next
- Browse what's supported in the integration catalog.
- Call connected capabilities with actions.
- Start jobs from provider events with triggers.
- Store your own credentials with the Secrets API.