InfraStudio Agents Start free

Reference

Integrations

Every tool you can connect, what it is for, where its key lives, and how it is tested.

Last updated

An integration connects the agents to a tool you already use: your AI account, your code, your issues, your numbers and errors, or the place where you get messages. You connect them on the Integrations page.

A key is a secret text from the tool, such as an API key or a token. The platform keeps it safe. You can see a short fingerprint of it, never the key itself.

Your AI account

Anthropic

Runs the agents on Claude with your Anthropic API key, through Claude Code. Anthropic bills your account for what the agents use.

  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: API key. In the Anthropic Console: Settings → API keys. It starts with sk-ant-api.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

OpenAI

Runs the agents on OpenAI's models with your API key, through Codex. OpenAI bills your account for what the agents use.

  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: API key. On platform.openai.com: API keys. A project key limited to the Responses API is enough.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

AWS Bedrock

Runs the agents on Claude in your own AWS account, through Claude Code. AWS bills you for what the agents use.

  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: AWS access. JSON with region, access_key_id and secret_access_key of an IAM user that may only call bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream. Its fields: region, access_key_id and secret_access_key.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

Azure OpenAI

Runs the agents on your Azure OpenAI deployment, through Codex.

  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: Connection. JSON with endpoint (https://<resource>.openai.azure.com) and api_key. Name the deployment as the model in the product's settings. Its fields: endpoint and api_key.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

OpenAI-compatible endpoint

Runs the agents on any endpoint that speaks OpenAI's Responses API, through Codex: a gateway or a model you host.

  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: Connection. JSON with base_url (ending in /v1) and api_key. Its fields: base_url and api_key.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

Where your code lives

GitHub

Lets the platform read the repository, add the agents' branches (their own copies of the code), open pull requests and put their changes into your code, and follow the automatic tests. Only the platform uses it; the agents never get it.

  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: Fine-grained token. Access to the repositories it's for only: Contents and Pull requests read and write, Actions and Metadata read.
  • How it is tested: Save and test checks the key at once, and Test checks it again later. A shared key is tested from a product, because the test needs a repository.

Where requests come from

Jira

A Jira issue that gets the Issue implementer's label becomes a plan and a pull request, and we comment on the Jira issue to say so.

  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: Site and token. JSON with site (https://<you>.atlassian.net), email and api_token: an Atlassian API token (a key from Atlassian) of an account that can comment on the project's issues. Its fields: site, email and api_token.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

Your numbers and errors

Google Analytics 4

The Product analytics review reads GA4 through Google's read-only MCP server.

  • Needed by: Product analytics review, which needs this or PostHog.
  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: Service account key. The JSON key of a service account with Viewer access to the GA4 property.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

PostHog

The Product analytics review and the chat read product analytics (events, funnels, retention, replays) through PostHog's MCP server, read-only.

  • Needed by: Product analytics review, which needs this or Google Analytics 4.
  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: Personal API key. In PostHog: Settings → Personal API keys → the “MCP Server” preset, limited to this project. Put the PostHog project ID in the product's settings.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

Sentry

The Product analytics review reads errors and performance through Sentry's MCP server.

  • Needed by: Error triage.
  • Where the key lives: One key for every product of the workspace, or one product's own key. A product without its own key uses the shared one.
  • What you enter: Auth token. A key from Sentry (an auth token) with read scopes only: org:read, project:read, event:read.
  • How it is tested: Save and test checks the key at once, and Test checks it again later.

Microsoft Clarity

The Collector (Clarity) saves Clarity's numbers on its schedule, for the Product analytics review.

  • Where the key lives: Each product has its own key.
  • What you enter: Data export token. In Clarity: Settings → Data export.
  • How it is tested: Clarity allows 10 requests a day, so the Collector (Clarity) itself is the test.

Where we message you

Slack

Your agents' news in a Slack channel: a product's own, or the workspace's. Team plan.

  • Where the key lives: One for the whole workspace.
  • What you enter: Nothing. Add to Slack connects the app, and Slack adds the key.
  • Plan: The Team or Enterprise plans.
  • How it is tested: Test checks the connection with Slack.

More ways to connect