Integrations are how the operator reaches the tools your team already uses. On its own, Kaer is a working environment; once a service is connected, the operator can read from it and act in it during a turn. This page covers the connect flow, how scopes keep each connection contained, and how to run the operator on your own model keys. It complements Connectors, which is the at-a-glance control room for the same set of links.
What you can connect
The operator connects to the services around the work, not just to a model. The common connections are:
- GitHub — repository access so the operator can read code and open pull requests.
- Slack — routing alerts and summaries into a channel when a job is done.
- Google — email and related account access.
- Stripe — payments, for operators that build or run billing flows.
- Notion — reading and writing pages and databases.
- Linear — reading issues and moving work through a board.
- Mail AI — outbound delivery; its deeper controls live on the Mail AI page.
- Webhooks — pushing events from Kaer into your own systems.
Once a service is connected, the operator can use it inside a turn: reading a Linear issue, opening a GitHub pull request, or posting to Slack the moment a task finishes.
Connecting a service
Open Connectors, pick the service you want, and authorize it. The link is tied to the workspace, so once it is set up the rest of the team can use it without each person connecting it again. The page keeps the answers you care about close together: whether you are connected, which account is in use, and where output is going.
Connect only what you already know you need. For most operational teams, GitHub and Slack come first, Mail AI follows when delivery moves outside the dashboard, and webhooks are worth adding once you are ready to push events into other internal systems.
Scopes and safety
Every connection is scoped. You grant only the access a service actually needs, and Kaer records what was granted. Because each integration is independent, you can revoke any single one without breaking the others — pulling a Slack token does not disturb your GitHub link.
Scoped tokens are stored encrypted and are only used when the operator runs a turn that needs them. They are not shown back in logs or responses. Connecting a service is not the same as handing it over: the operator still works within the access you granted, and the practical footprint of any session stays small. For how stored credentials are protected, see Security.
Bring your own keys
You can run the operator on your own model and provider keys. Instead of relying on platform-managed access, you connect the keys for the providers you already have accounts with, so model usage runs through infrastructure and billing you control.
This is useful when you have existing provider agreements, want usage to show up on your own account, or need model traffic to follow contracts you already have in place. The keys are stored with the same encrypted, scoped handling as any other connected credential, and they are only used when a turn calls the corresponding provider. New to the product? Start with Getting Started and connect your first service once you have run a turn.