Available integrations
Pick the connection style based on where the research should happen — inside an agent client, your own app, or team chat.
MCP clients
Run Cortexa inside Claude, Cursor, Codex, Windsurf, Zed, and remote MCP clients.
Developer API
OpenAI-compatible or native streaming for cited research in your own app.
Slack app
Ask Cortexa in a thread and get the answer there: @mention it, DM it, or use /cortexa. Attachments, computation, generated files, and a link back to the same session in Cortexa.
GitHub
Read selected private repositories through a read-only GitHub App with commit-pinned citations.
Private connections
Grant selected users or roles read access to Postgres, BigQuery, GitHub, Slack channel history, Amazon S3 and Google Cloud Storage buckets, Bitquery on-chain data, and any REST API of your own.
Your own REST API
Add a base URL and its credentials — a bearer token, an API key in a header or query parameter, a username and password, or OAuth client credentials. Cortexa works out what the API offers and reads from it.
Slack appears twice, and they are different things
The Slack app is a place to ask from: you talk to Cortexa in a channel or DM and it replies in the thread. A Slack connection is a place to read from: a read-only token that lets the agent search channel history as evidence, the same way it reads a database. Adding one does not add the other, and either works on its own — the app can answer in Slack without ever reading your history.
What a connection reaches
Once a private connection exists, the same read-only, per-user path serves every surface — nothing gets its own way into your data.
Agent tools in chat
Cortexa lists your connections, inspects their schema, and runs read-only queries — Postgres and BigQuery tables, Slack channels, GitHub repositories, files under an allowed bucket prefix in S3 or Cloud Storage, Bitquery GraphQL, and endpoints on a connected REST API.
Dashboards
A dashboard generated from a connected session keeps each panel's query and can re-read the source on demand.
One authorization path
Every read re-checks the caller against the connection's owner, workspace, and explicit grants, and is written to the audit trail.
These tools are listed, not public
Private-connection tools appear in the tool catalog so you can see what Cortexa can do with a connection. They read only the sources you attach — there is no shared or public data behind them, and they do nothing for a visitor who has connected nothing.
How a REST API connection finds its way around
You are not asked to list your endpoints. When the agent first uses the connection it reads the API's OpenAPI or Swagger description if one is published, looks for it at the usual addresses if you haven't named it, and otherwise inspects the API itself — following the links a self-describing response returns. If none of that yields anything it says so, and the short description you can write on the connection is what it falls back on. Every request is a read: only
GET, HEAD and OPTIONS are ever sent, nothing can leave the base URL you set, and you can narrow it further to named path prefixes.Setup pattern
Choose an organization owner, grant the minimum users, roles, channels, keys, and provider resources required, then test before expanding access.
- 01
Create a named key
Use one key per client or environment so ownership and revocation stay precise.
- 02
Configure the client
Copy the MCP, API, or Slack settings from the matching guide and keep secrets out of source control.
- 03
Run a smoke request
Ask a small cited question first. Confirm the response, sources, and workspace attribution.
- 04
Review and expand
Check recent usage and key ownership before connecting broader team workflows.
Monitoring
Keep ownership visible once an integration is live — key ownership, recent traffic, and which workspace owns the client.