Skip to main content
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 for an overview. Use the CLI to search the live catalog and inspect the exact action schema before writing code:

Two built-in paths

Built-in apps currently fall into two broad paths. 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.
Then attach the action or tool in code:
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:
See external channels for the full workflow across the three Slack connection kinds.

Use built-in actions

Built-in actions are normal actions. You can use them as workflow steps or agent tools, and their credentials resolve the same way as yours. Import generated tools from @keystrokehq/<app>/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.
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 a user credential to the step or tool. See using credentials in code.

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 and manage apps

Connect catalog apps and manage their credential instances.

Using credentials in code

Learn how built-in actions resolve credentials at runtime.

Integrations catalog

Browse available apps and actions.

Custom apps and MCP

Register connectable apps and author them with defineApp.