> ## Documentation Index > Fetch the complete documentation index at: https://keystroke.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Built-in integrations > Use built-in OAuth apps and managed integrations. Keystroke ships a catalog of built-in apps you can connect and use from agents and workflows. A built-in app usually gives you one or both of these: * **Actions** you can call as workflow steps or agent tools. * **Credentials** you can connect through the web app or CLI. Browse the public [integration catalog](/docs/integrations) for an overview. Use the CLI to search the live catalog and inspect the exact action schema before writing code: ```bash theme={null} keystroke apps search "calendar" keystroke apps actions list googlecalendar --search "events" keystroke apps actions get googlecalendar ``` ## Two built-in paths Built-in apps currently fall into two broad paths. | Path | Examples | Credential kind | Best for | | -------------------------- | --------------------------------------------------- | --------------- | -------------------------------------------------------------------------------------- | | **Managed app connection** | Google Workspace, GitHub, Gong, Snowflake, Slackbot | `keystroke` | OAuth-style catalog apps whose tools run through Keystroke's hosted platform MCP layer | | **Static API key app** | Exa | `api_key` | Apps where you paste an API key into the credential vault | Some app names overlap with gateway surfaces. Slack is the common case: connect **`slackbot`** to act as the bot (send messages and any other Slack action) and for External Channels; connect **`slack`** only when actions must appear as the installing user. Connecting `slack` does not register a gateway workspace. ## Managed app connections Managed app connections are the default path for many catalog integrations. In code, generated actions declare a credential for the app. At runtime, Keystroke resolves that credential and routes the tool call through the hosted platform MCP layer. From your workflow or agent, they still look like normal actions: import the generated action from the app package and call `.run()` or attach it as a tool. Managed catalog apps that use Keystroke's platform MCP layer are a hosted-cloud feature. Connect these apps from the Apps page in the web app. When a connection completes, Keystroke creates credential instances for the selected organization, user, or projects. ## Static API key apps Some built-in apps use a normal API key. Exa is the common example. Store the key in the credential vault, then use the package's actions or MCP tools. ```bash theme={null} keystroke credentials create exa --set apiKey=@env:EXA_API_KEY --scope org ``` Then attach the action or tool in code: ```ts theme={null} import { defineAgent } from "@keystrokehq/keystroke/agent"; import { exaSearch } from "@keystrokehq/exa/actions"; export default defineAgent({ slug: "researcher", name: "Researcher", description: "Uses Exa for current web research.", systemPrompt: "Use Exa when you need current web research.", model: "openai/gpt-5.6-sol", tools: [exaSearch], }); ``` The action receives the API key at runtime; the agent only sees the tool interface and result. ## Gateway apps Gateway apps connect a messaging surface to an agent. Slack is the shipped gateway today. Connect the **Keystroke Slack App** (catalog slug `slackbot` — not a Personal Slack Account) so the bot OAuth is mirrored into the gateway workspace, then bind channels to agents. Use the agent's External Channels panel in the web app, or the CLI: ```bash theme={null} keystroke connect slack --kind keystroke keystroke channels platforms list keystroke channels accounts --platform slack keystroke channels bind support --platform slack --account --channel ``` See [external channels](/docs/learn/agents/external-channels) for the full workflow across the three Slack connection kinds. ## Use built-in actions Built-in actions are normal [actions](/docs/learn/actions/overview). You can use them as [workflow steps](/docs/learn/actions/workflow-steps) or [agent tools](/docs/learn/actions/agent-tools), and their credentials resolve the same way as yours. Import generated tools from `@keystrokehq//actions`. For VM sandbox credentials only, import the app from the package root (`import { github } from "@keystrokehq/github"`) and use `github.credential` — project builds tree-shake unused actions. Before composing an action, check the connected credentials and execute it once against the intended account. This verifies real IDs, permissions, custom fields, and the mutating path—not only the action schema. ```bash theme={null} keystroke credentials list keystroke apps execute --input '{...}' ``` ```ts theme={null} // Workflow step await slackSendMessage.run({ channel, markdown_text }); // Agent tool tools: [slackSendMessage.scope("user")], ``` Pin a scope when the action should use a user credential or when you need to avoid the default project → organization resolution chain. For `.scope("user")`, [assign](/docs/learn/credentials/connect-credentials#bind-a-credential-to-a-step-tool-or-poll-action) a user credential to the step or tool. See [using credentials in code](/docs/learn/credentials/use-credentials). ## Downloadable file results Some managed catalog tools return downloadable files as `{ name, s3url, mimetype }`. For text-like MIME types, Keystroke fetches the file and adds a `text` field so agents can read the content directly. The `s3url` is kept. If content is not inlined (binary files, oversized files, or a failed fetch), the result includes a `note` telling the agent to use the built-in `web_fetch` tool on the `s3url`. ## Next steps Connect catalog apps and manage their credential instances. Learn how built-in actions resolve credentials at runtime. Browse available apps and actions. Register connectable apps and author them with `defineApp`.