{
  "schemaVersion": "1.0",
  "title": "Connector catalog",
  "description": "Use this catalog to choose the product boundary that matches your integration. Each connector translates a bounded provider API and event surface into AIP capabilities, contracts, lifecycle state, and errors. The connector does not change t",
  "canonical": "https://getaip.org/docs/connectors",
  "route": "/docs/connectors",
  "source": "docs/connectors/README.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Documentation",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "d7cce13d1d555644d04a4d73c66c95b113737635",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/connectors.md",
    "txt": "/docs/download/connectors.txt",
    "json": "/docs/download/connectors.json",
    "pdf": "/docs/download/connectors.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Connector catalog\ndescription: Choose a maintained AIP connector and enter its product-specific documentation\nkind: index\naudience: developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"d7cce13d1d555644d04a4d73c66c95b113737635\"\n---\n\n# Connector catalog\n\nUse this catalog to choose the product boundary that matches your integration.\nEach connector translates a bounded provider API and event surface into AIP\ncapabilities, contracts, lifecycle state, and errors. The connector does not\nchange the AIP 1.0 wire protocol.\n\nThe current public catalog contains six maintained product connectors. Each\nhas a connector crate and a standalone host package at the reviewed source\nrevision. Source presence establishes implementation scope only; qualification\nand live-product evidence remain separate claims.\n\nThis catalog targets source revision\n`d7cce13d1d555644d04a4d73c66c95b113737635`. The authoring pass inspected code\nand deployment artifacts without building a host, starting a service, or\ncontacting a provider.\n\n## Choose a connector\n\n| Connector | Choose it when you need | Current provider boundary |\n|---|---|---|\n| [Cal.diy](/docs/connectors/cal-diy) | Scheduling, availability, bookings, calendars, conferencing, or booking webhooks | Versioned Cal.diy API operations, account-aware credentials, mutation fencing, reconciliation, and signed webhook ingress |\n| [Hermes Agent](/docs/connectors/hermes-agent) | Hermes API-server discovery, chat, responses, structured runs, sessions, or governed operator behavior | One or more configured Hermes endpoints with endpoint identity, optional tenant binding, and opt-in operator policy |\n| [Chatwoot](/docs/connectors/chatwoot) | Customer-support accounts, conversations, messages, contacts, inboxes, teams, automation, or webhooks | A frozen account-scoped operation set, API-token authentication, and signed replay-fenced webhook ingress |\n| [Dify](/docs/connectors/dify) | Dify applications, workflows, conversations, media, human input, annotations, or knowledge resources | Separate application and knowledge-workspace credentials with bounded operation and response handling |\n| [CrewAI](/docs/connectors/crewai) | Versioned crews, runs, status, events, cancellation, replay, training, testing, knowledge, or memory reset | An authenticated Rust-to-Python sidecar boundary with connector-owned AIP identity and lifecycle state |\n| [Twenty](/docs/connectors/twenty) | Workspace CRM records, duplicate detection, aggregation, metadata, OpenAPI discovery, or webhooks | Fixed REST operations over validated object and resource identifiers, header-only authentication, governed mutations, and signed webhook ingress |\n\nThese connectors are not arbitrary HTTP proxies. Their manifests, schemas,\npath construction, credential rules, risk, approval, idempotency, and response\nlimits define the callable surface.\n\n## Choose by operational boundary\n\nProduct fit is necessary but not sufficient. Before adopting a connector,\nanswer these questions:\n\n1. Which exact provider account, workspace, application, endpoint, or sidecar\n   does one connector instance own?\n2. Which tenant is authorized to discover and invoke that instance?\n3. Which calls read data, mutate data, or permanently delete data?\n4. Which mutations require approval, idempotency, reconciliation, or\n   compensation?\n5. Does the provider deliver webhooks or streaming output, and where is replay\n   state stored?\n6. How are provider credentials referenced, rotated, and revoked without\n   entering the registry or manifest?\n7. What exact implementation, qualification, and live-product evidence exists\n   for the artifact you plan to deploy?\n\nOpen the connector overview before selecting capability IDs. The overview owns\nthe provider boundary, deployment shape, upstream baseline, safety constraints,\nand evidence status for that connector.\n\n## Understand the common host model\n\nAll six product connectors can run behind the common standalone host boundary.\nThe product-neutral `getaip-server` process routes admitted actions; the host owns the\nprovider client, provider credentials, connector implementation, replica\nlifecycle, and product-specific ingress.\n\nThe common bootstrap provides registration, heartbeat, readiness, drain,\noffline transition, signed control-plane communication, gateway authentication,\ncredential references, resource limits, and remote dispatch. Product hosts add\nonly the configuration and HTTP mounts required by their provider.\n\nProvider secrets are read by the host from deployment-owned files or secret\nreferences. They are not capability metadata, registry catalog values, or\ncaller input. A connector instance is not ready merely because its process or\nhealth route is reachable; admission, registration, leases, credentials, and\nprovider prerequisites also matter.\n\nThe legacy bundled daemon remains a migration boundary. New fleet deployments\nshould not compile product-specific connector clients into the product-neutral\ndaemon.\n\n## Read source and evidence cues correctly\n\n| Connector | Source-side evidence available at this revision | What remains a separate claim |\n|---|---|---|\n| Cal.diy | Connector and host source plus a dedicated isolated qualification harness | Whether a named Cal.diy artifact completed that harness and remains compatible now |\n| Hermes Agent | Connector and host source plus a two-endpoint smoke topology | Whether an exact Hermes artifact passed the intended operation and operator matrix |\n| Chatwoot | Connector and host source plus the deterministic five-product fleet profile | Live Chatwoot behavior, isolated qualification, and production operation |\n| Dify | Connector and host source plus the deterministic five-product fleet profile | Live Dify behavior, isolated qualification, and production operation |\n| CrewAI | Connector, host, sidecar, and deterministic fleet-sidecar source | Qualification of an exact crew registry, sidecar image, recovery path, and provider dependencies |\n| Twenty | Connector and host source | A dedicated example, reference-fleet product profile, isolated qualification, or live-product run |\n\nThe deterministic product-fleet profile uses controlled upstream fixtures for\nCal.diy, Hermes Agent, Chatwoot, Dify, and CrewAI. It tests fleet and connector\nmechanics but does not constitute live verification against those products.\nTwenty is not part of that profile at the reviewed revision.\n\nDo not copy an evidence statement from one connector to another. Record the\nconnector version, upstream revision, image digest, configuration identity,\ntenant, procedure, timestamp, and retained result for every qualification or\nlive claim.\n\n## Navigate connector documentation\n\nOpening a catalog entry changes from global protocol documentation to the\nselected connector's local documentation context. Each connector keeps the\nstable overview route shown above and organizes deeper pages by reader task:\n\n| Local section | Use it for |\n|---|---|\n| Overview | Product boundary, version, deployment choice, capability groups, and evidence |\n| Getting started | Credentials, tenant routing, first discovery, and first bounded call |\n| Capabilities | Operation groups, contracts, inputs, outputs, side effects, and errors |\n| Guides | Product workflows that combine several operations safely |\n| Reference | Configuration, provider routes, webhooks, limits, and exclusions |\n| Operations | Deployment, readiness, metrics, recovery, and credential rotation |\n| Troubleshooting | Symptom-led diagnosis and outcome-unknown decisions |\n| Qualification and changelog | Exact evidence, compatibility, migrations, and deprecations |\n\nThe global sidebar keeps one Connector Catalog entry instead of listing every\nproduct page. This keeps navigation usable as the catalog grows. Connector-local\nmenus can expand independently without changing protocol and operator\nnavigation.\n\n## Add or migrate a connector\n\nUse [Build a connector](../guides/build-a-connector.md) when no catalog entry\nowns the provider boundary. A new connector needs an immutable identity,\nbounded provider surface, source-owned schemas, contracts, secret references,\nstandalone host composition, negative tests, and qualification scope before it\ncan join the public catalog.\n\nDo not add an arbitrary passthrough connector as a shortcut. Dynamic long-tail\ncatalogs still need explicit authority, path, schema, side-effect, credential,\nand evidence boundaries.\n\n## Related documentation\n\n- [Profiles and connectors](../concepts/profiles-and-connectors.md)\n- [Connector-fleet quickstart](../getting-started/connector-fleet-quickstart.md)\n- [Examples and reference deployments](../guides/examples-and-reference-deployments.md)\n- [Build a connector](../guides/build-a-connector.md)\n- [Installation](../getting-started/installation.md)\n",
    "text": "Connector catalog\n\nUse this catalog to choose the product boundary that matches your integration.\nEach connector translates a bounded provider API and event surface into AIP\ncapabilities, contracts, lifecycle state, and errors. The connector does not\nchange the AIP 1.0 wire protocol.\n\nThe current public catalog contains six maintained product connectors. Each\nhas a connector crate and a standalone host package at the reviewed source\nrevision. Source presence establishes implementation scope only; qualification\nand live-product evidence remain separate claims.\n\nThis catalog targets source revision\nd7cce13d1d555644d04a4d73c66c95b113737635. The authoring pass inspected code\nand deployment artifacts without building a host, starting a service, or\ncontacting a provider.\n\nChoose a connector\n\n| Connector | Choose it when you need | Current provider boundary |\n\n| Cal.diy (/docs/connectors/cal-diy) | Scheduling, availability, bookings, calendars, conferencing, or booking webhooks | Versioned Cal.diy API operations, account-aware credentials, mutation fencing, reconciliation, and signed webhook ingress |\n| Hermes Agent (/docs/connectors/hermes-agent) | Hermes API-server discovery, chat, responses, structured runs, sessions, or governed operator behavior | One or more configured Hermes endpoints with endpoint identity, optional tenant binding, and opt-in operator policy |\n| Chatwoot (/docs/connectors/chatwoot) | Customer-support accounts, conversations, messages, contacts, inboxes, teams, automation, or webhooks | A frozen account-scoped operation set, API-token authentication, and signed replay-fenced webhook ingress |\n| Dify (/docs/connectors/dify) | Dify applications, workflows, conversations, media, human input, annotations, or knowledge resources | Separate application and knowledge-workspace credentials with bounded operation and response handling |\n| CrewAI (/docs/connectors/crewai) | Versioned crews, runs, status, events, cancellation, replay, training, testing, knowledge, or memory reset | An authenticated Rust-to-Python sidecar boundary with connector-owned AIP identity and lifecycle state |\n| Twenty (/docs/connectors/twenty) | Workspace CRM records, duplicate detection, aggregation, metadata, OpenAPI discovery, or webhooks | Fixed REST operations over validated object and resource identifiers, header-only authentication, governed mutations, and signed webhook ingress |\n\nThese connectors are not arbitrary HTTP proxies. Their manifests, schemas,\npath construction, credential rules, risk, approval, idempotency, and response\nlimits define the callable surface.\n\nChoose by operational boundary\n\nProduct fit is necessary but not sufficient. Before adopting a connector,\nanswer these questions:\n1. Which exact provider account, workspace, application, endpoint, or sidecar\n   does one connector instance own?\n2. Which tenant is authorized to discover and invoke that instance?\n3. Which calls read data, mutate data, or permanently delete data?\n4. Which mutations require approval, idempotency, reconciliation, or\n   compensation?\n5. Does the provider deliver webhooks or streaming output, and where is replay\n   state stored?\n6. How are provider credentials referenced, rotated, and revoked without\n   entering the registry or manifest?\n7. What exact implementation, qualification, and live-product evidence exists\n   for the artifact you plan to deploy?\n\nOpen the connector overview before selecting capability IDs. The overview owns\nthe provider boundary, deployment shape, upstream baseline, safety constraints,\nand evidence status for that connector.\n\nUnderstand the common host model\n\nAll six product connectors can run behind the common standalone host boundary.\nThe product-neutral getaip-server process routes admitted actions; the host owns the\nprovider client, provider credentials, connector implementation, replica\nlifecycle, and product-specific ingress.\n\nThe common bootstrap provides registration, heartbeat, readiness, drain,\noffline transition, signed control-plane communication, gateway authentication,\ncredential references, resource limits, and remote dispatch. Product hosts add\nonly the configuration and HTTP mounts required by their provider.\n\nProvider secrets are read by the host from deployment-owned files or secret\nreferences. They are not capability metadata, registry catalog values, or\ncaller input. A connector instance is not ready merely because its process or\nhealth route is reachable; admission, registration, leases, credentials, and\nprovider prerequisites also matter.\n\nThe legacy bundled daemon remains a migration boundary. New fleet deployments\nshould not compile product-specific connector clients into the product-neutral\ndaemon.\n\nRead source and evidence cues correctly\n\n| Connector | Source-side evidence available at this revision | What remains a separate claim |\n\n| Cal.diy | Connector and host source plus a dedicated isolated qualification harness | Whether a named Cal.diy artifact completed that harness and remains compatible now |\n| Hermes Agent | Connector and host source plus a two-endpoint smoke topology | Whether an exact Hermes artifact passed the intended operation and operator matrix |\n| Chatwoot | Connector and host source plus the deterministic five-product fleet profile | Live Chatwoot behavior, isolated qualification, and production operation |\n| Dify | Connector and host source plus the deterministic five-product fleet profile | Live Dify behavior, isolated qualification, and production operation |\n| CrewAI | Connector, host, sidecar, and deterministic fleet-sidecar source | Qualification of an exact crew registry, sidecar image, recovery path, and provider dependencies |\n| Twenty | Connector and host source | A dedicated example, reference-fleet product profile, isolated qualification, or live-product run |\n\nThe deterministic product-fleet profile uses controlled upstream fixtures for\nCal.diy, Hermes Agent, Chatwoot, Dify, and CrewAI. It tests fleet and connector\nmechanics but does not constitute live verification against those products.\nTwenty is not part of that profile at the reviewed revision.\n\nDo not copy an evidence statement from one connector to another. Record the\nconnector version, upstream revision, image digest, configuration identity,\ntenant, procedure, timestamp, and retained result for every qualification or\nlive claim.\n\nNavigate connector documentation\n\nOpening a catalog entry changes from global protocol documentation to the\nselected connector's local documentation context. Each connector keeps the\nstable overview route shown above and organizes deeper pages by reader task:\n\n| Local section | Use it for |\n\n| Overview | Product boundary, version, deployment choice, capability groups, and evidence |\n| Getting started | Credentials, tenant routing, first discovery, and first bounded call |\n| Capabilities | Operation groups, contracts, inputs, outputs, side effects, and errors |\n| Guides | Product workflows that combine several operations safely |\n| Reference | Configuration, provider routes, webhooks, limits, and exclusions |\n| Operations | Deployment, readiness, metrics, recovery, and credential rotation |\n| Troubleshooting | Symptom-led diagnosis and outcome-unknown decisions |\n| Qualification and changelog | Exact evidence, compatibility, migrations, and deprecations |\n\nThe global sidebar keeps one Connector Catalog entry instead of listing every\nproduct page. This keeps navigation usable as the catalog grows. Connector-local\nmenus can expand independently without changing protocol and operator\nnavigation.\n\nAdd or migrate a connector\n\nUse Build a connector (../guides/build-a-connector.md) when no catalog entry\nowns the provider boundary. A new connector needs an immutable identity,\nbounded provider surface, source-owned schemas, contracts, secret references,\nstandalone host composition, negative tests, and qualification scope before it\ncan join the public catalog.\n\nDo not add an arbitrary passthrough connector as a shortcut. Dynamic long-tail\ncatalogs still need explicit authority, path, schema, side-effect, credential,\nand evidence boundaries.\n\nRelated documentation\n• Profiles and connectors (../concepts/profiles-and-connectors.md)\n• Connector-fleet quickstart (../getting-started/connector-fleet-quickstart.md)\n• Examples and reference deployments (../guides/examples-and-reference-deployments.md)\n• Build a connector (../guides/build-a-connector.md)\n• Installation (../getting-started/installation.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "fc836188bc34115833b3dbe1ec42219e4dc67f218df1e7313aa2e4080b4cc3b4"
  }
}