Skip to main content
An integration connects a project capability to the Polycore catalog. Customer hosted runners keep private-network credentials in your infrastructure. Shared SaaS direct integrations use a separate private Polycore executor with encrypted provider grants and never expose those grants to callers or the public control plane. During early access, every integration is planned and implemented with the Polycore team. The pages in this section explain the architecture, IAM shape, configuration, and validation you can expect.
This is not a self-serve connector directory. If your system is not listed, request early access and describe the workflow. We add integrations around real customer requirements.

​
Direct SaaS integrations

Notion

A read-only, project-wide shared internal connection for company knowledge. Owners and admins install the connection; Notion page sharing remains the provider-side resource boundary.

Shared team authority

Direct integrations represent team resources rather than personal user accounts. Environment switching does not retarget project-wide connections.
Direct integrations are intentionally narrow. They use typed provider operations, fixed hosts, bounded requests and results, an isolated executor, and explicit MCP service grants. Use a runner for private networks, production databases, custom code, broad credentials, or customer-side credential custody.

​
Data platforms

Postgres

Read-only schema discovery, query planning, and bounded SQL through a customer-hosted runner. Works with standard Postgres, including hosted services such as Supabase.

Firestore

Document and collection-group reads, server-side aggregations, live shape inference, and optional Typesync grounding through GCP IAM.

PostHog

Bounded HogQL, taxonomy discovery, behavioral segmentation, enrichment, and activity context for composition with live operational data.
Built-in data queries are read-only. Actions that change state and multi-system workflows are represented as customer actions with explicit schemas, hazards, and secret needs.

​
Interfaces

Slack

A conversational agent for everyday requests, plus human approval cards for pending writes.

MCP

Expose the same connected catalog to AI agents and development tools through a control-plane MCP endpoint.
Admin dashboards are another interface to the same catalog. They are described under Admin dashboards because they compose connected capabilities rather than add another downstream credential.

​
Anatomy of an integration

1. Capability surface

Enabled built-in query families plus named actions. This is the complete catalog the runner advertises.

2. Domain context

A concise project document that explains terms, identifiers, and safe interpretation rules to the agent.

3. Runtime identity

One runner registration for one Polycore project and environment, plus the cloud or network identity used inside that environment.

4. Deployment path

A repository, container image, infrastructure definition, and secret injection path owned by your team.

​
Read and write paths

Enable a built-in query family and bind a read-only identity. The agent can inspect the schema and compose bounded reads without a custom action for every question.

​
Integration principles

We choose a valuable production read and a representative governed change before choosing implementation details.
Workload identity, database URLs, and private API keys are resolved by the runner in your infrastructure. Shared SaaS grants are encrypted and used only inside the isolated hosted executor, not stored in public control-plane metadata.
IAM, SQL grants, restricted API keys, and network controls remain the first enforcement layer.
Query families, actions, schemas, and project context live in your runner. Changes reach a deployed instance through your deployment.
A successful demo is not enough. We validate missing permissions, denied writes, unavailable runners, bounded results, and audit records.

​
Adding another platform

A new platform usually needs some combination of:
  1. A least-privilege identity and deployment binding.
  2. A constrained generic read surface, when the platform has a broad query model.
  3. Named actions for stable operations and writes.
  4. Tool descriptions and project context that let agents choose the surface correctly.
  5. Integration tests and an operational deployment path.
Have a platform or internal API you want to connect? Include it in your early-access request. We will assess it against the workflow and trust model with you.