Connect to the systems
your business already runs on
35+ native connectors, a typed connector SDK, and a credential vault that means agents never touch a secret. Every connector call is audited.
Connector library
Native connectors are maintained in the platform. “Via Connector SDK” means you can configure them using the same SDK — without custom code.
ServiceNow
Native
Jira Service Mgmt
Native
Zendesk
Native
Freshdesk
Native
ManageEngine
Native
PagerDuty
Native
Salesforce
Native
HubSpot
Native
Zoho CRM
Native
Pipedrive
Via Connector SDK
Slack
Native
Microsoft Teams
Native
WhatsApp Business
Native
Email (SMTP/IMAP)
Native
Telegram
Via Connector SDK
PostgreSQL
Native
MySQL
Native
Elasticsearch
Native
Confluence
Native
SharePoint
Native
Notion
Via Connector SDK
Google Drive
Via Connector SDK
Okta
Native
Azure Active Dir.
Native
LDAP / OpenLDAP
Native
SAML 2.0
Native
Google Workspace
Via Connector SDK
Shopify
Native
AWS
Native
Azure
Native
Google Cloud
Native
On-Premise Servers
Native
Kubernetes
Via Connector SDK
OpenAI GPT-4o
Native
Azure OpenAI
Native
Anthropic Claude
Native
Google Gemini
Native
Private / Self-hosted
Native
Ollama (local)
Via Connector SDK
Need a connector that's not in the library?
The Connector SDK lets you define typed connectors that participate in the same credential vault, audit logging, and permission machinery as native connectors. Build once, govern the same way.
How integrations actually work
The design choices behind the connector layer — why agents never hold secrets, how permissions are enforced, and what extensibility looks like without compromising governance.
Connector, not integration spaghetti
Every integration runs through a typed connector interface. Credentials are stored once, in a vault, and referenced by name. Agents never hold connection strings — they call a named connector. This makes auditing, rotation, and access revocation a configuration change, not a code change.
- Typed connector spec (source, action, auth method, schema)
- Credential vault with per-connector access policies
- Connector health status surfaced in the control plane
- Zero connector credentials in agent prompt or memory
Least-privilege by construction
Each connector declares a capability set — read, write, delete, admin. Agents are assigned connectors with explicit capability caps at deployment time. The platform enforces capability boundaries at the connector layer; agents cannot escalate their own permissions.
- Capability caps: read / write / delete / admin per connector
- Agents bound to declared connector list at deployment
- Runtime permission checks before every connector invocation
- Audit log entry on every connector call (agent, connector, action, outcome)
Custom connectors without forking the platform
If a system isn't in the native library, the connector SDK lets you define one — in your language, deployed in your environment. Custom connectors participate in the same credential vault, audit, and permission machinery as built-in connectors. You don't compromise on governance to get extensibility.
- Connector SDK with typed request/response schemas
- Webhook receiver primitive for inbound event-driven triggers
- REST, GraphQL, gRPC, and database transport support
- Custom connectors version-pinned per deployment
The model is a connector, not the foundation
LLMs are treated as connectors — not as the platform itself. This means you can swap, pin, or route across models without changing agent logic. A customer support agent can use a fast model for classification and a reasoning model for resolution. The routing policy lives in the control plane.
- Per-agent model assignment with version pinning
- Multi-model routing within a single agent workflow
- Latency, cost, and capability-based routing policies
- Private / self-hosted model support (Ollama, vLLM, custom endpoints)
Connectors work the same way
regardless of where you deploy
Whether you run Orchestrik on-premise behind your firewall, in a private cloud VPC, or as a managed SaaS tenant — the connector interface, credential model, and audit format are identical. Migrations between deployment modes don't require connector rewrites.
What's consistent across deployment modes
- Credential vault API and secret format
- Connector capability model (read/write/delete/admin)
- Audit log schema and retention controls
- Custom connector SDK version and interface
- Model connector configuration and routing rules
- Health monitoring and connector status surface
What's available for technical evaluation
Enterprise evaluations include full access to connector specifications, credential architecture documentation, and the SDK reference. We don't make you reverse-engineer the integration model from a demo.
Connector specification reference
Full typed schema for every native connector
Credential vault architecture
How secrets are stored, rotated, and scoped
Connector SDK documentation
Build and deploy custom connectors
Audit log schema
Field-level specification for all connector audit events
Model routing configuration guide
Multi-model setup, version pinning, fallback policies
See the connector library in a live environment
We'll walk you through the connector model, credential architecture, and custom SDK with a live instance connected to the systems you actually use.