{
  "schemaVersion": "1.0",
  "title": "Deploy the Twenty connector",
  "description": "Use this procedure to deploy one standalone aip-host-twenty instance. The host owns AIP identity, fixed provider workspace access, durable Action state, optional webhook replay, local events, and central publication.",
  "canonical": "https://getaip.org/docs/connectors/twenty/operations/deployment",
  "route": "/docs/connectors/twenty/operations/deployment",
  "source": "docs/connectors/twenty/operations/deployment.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/twenty/operations/deployment.md",
    "txt": "/docs/download/connectors/twenty/operations/deployment.txt",
    "json": "/docs/download/connectors/twenty/operations/deployment.json",
    "pdf": "/docs/download/connectors/twenty/operations/deployment.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Deploy the Twenty connector\ndescription: >-\n  Deploy one immutable standalone host with fixed workspace identity, durable\n  state, admitted routing, and optional webhook ingress\nkind: how-to\naudience: operator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: twenty\naliases:\n  - Twenty connector deployment\n  - Deploy aip-host-twenty\n---\n\n# Deploy the Twenty connector\n\nUse this procedure to deploy one standalone `aip-host-twenty` instance. The\nhost owns AIP identity, fixed provider workspace access, durable Action state,\noptional webhook replay, local events, and central publication.\n\nThe reviewed connector-fleet Compose file does not contain a Twenty service.\nUse the source-owned binary and generic host image as inputs to a separately\nreviewed deployment rather than treating that Compose topology as a template.\n\n## Fix the deployment unit\n\nOne logical instance requires:\n\n| Component | Role | Durable ownership |\n|---|---|---|\n| `aip-host-twenty` | AIP endpoint, provider mapping, health, webhook ingress | Connector runtime PostgreSQL |\n| Twenty deployment | Fixed record and metadata provider | Provider-owned workspace state |\n| Connector control plane | Type, version, instance, replica, lease, lifecycle | Registry and admission state |\n| AIP gateway | Signed tenant traffic and route selection | Gateway runtime state |\n| Private ingress | Host AIP, lifecycle, and optional webhook routes | TLS and routing configuration |\n| Secret manager | Database URL, signing seed, API token, optional webhook secret | Versioned secret material |\n\nThe Twenty provider does not run inside the connector host. Keep its lifecycle,\nbackup, schema, and credential ownership separate from the AIP artifact.\n\n## 1. Freeze the host artifact\n\nThe generic host Dockerfile accepts this exact package and binary pair:\n\n```text\nPACKAGE=aip-host-twenty\nBINARY=aip-host-twenty\n```\n\nA representative source build is:\n\n```sh\ndocker build \\\n  --file deploy/connector-fleet/Dockerfile.host \\\n  --build-arg PACKAGE=aip-host-twenty \\\n  --build-arg BINARY=aip-host-twenty \\\n  --build-arg SOURCE_REVISION=97be86e9efedf07ecf1783b03800f683f107fb04 \\\n  --build-arg IMAGE_VERSION=1.0.0 \\\n  --tag getaip/aip-host-twenty:reviewed \\\n  .\n```\n\nRun this command only from a clean checkout whose exact revision and lockfiles\nhave passed the deployment's build policy. The mutable example tag is not an\nartifact identity.\n\nThe runtime image:\n\n- uses a pinned Alpine base in source;\n- runs as UID and GID `10001`;\n- exposes port `8081`;\n- installs the binary as `/usr/local/bin/aip-connector-host`;\n- uses that binary as its entrypoint;\n- checks loopback `/health` with `wget`.\n\nRetain immutable OCI digest, source revision, Cargo lock identity, provenance,\nsoftware bill of materials, vulnerability decision, labels, and build logs.\n\nThe source-owned product image verifier includes `aip-host-twenty`, checks its\nhelp output, non-root user, entrypoint, component label, revision, and version.\nThat build check is input to deployment review, not runtime qualification.\n\n## 2. Admit the artifact and instance\n\nCreate or verify an immutable connector type and version before starting the\nreplica. Bind the version to the exact image digest and required evidence.\n\nProvision unique values for:\n\n- connector instance ID;\n- connector replica ID;\n- tenant and membership IDs;\n- external-account ID and system;\n- artifact digest and configuration revision;\n- region, zone, capacity class, and trust domain;\n- provider workspace UUID and credential revision.\n\nFor a tenant-owned workspace, deployment policy should require external-account\nID to equal the configured workspace UUID. The host does not enforce that\nequality automatically.\n\nDo not reuse a replica ID for two running processes. Do not change the provider\nworkspace behind an unchanged logical instance without a new admission and\nconfiguration decision.\n\n## 3. Provision owner-controlled files\n\nMount these required host inputs:\n\n| Input | Secret | Purpose |\n|---|---:|---|\n| PostgreSQL URL file | Yes | Durable runtime, replay, event, and outbox stores |\n| Ed25519 signing-seed file | Yes | Host response, lifecycle, and callback identity |\n| Twenty API-token file | Yes | Fixed provider Bearer authentication |\n| Gateway DID file or value | No | Verify signed gateway traffic |\n| Control-plane DID file or value | No | Verify lifecycle responses |\n| Private CA file | No | Validate private deployment TLS when used |\n| Operation allowlist file | No | Non-empty subset of 22 fixed suffixes |\n| Credential-revision policy file | No | Reloadable fail-closed authority fence |\n\nThe database URL and API token have 16 KiB file bounds. The signing seed has a\n256-byte file bound and must encode exactly 32 bytes as hexadecimal. The\noperation file has a 128 KiB bound.\n\nSecret files must be regular, non-symlink, owner-controlled inputs with no group\nor world permission bits on Unix. Mount them read-only to the host.\n\nProvision the optional webhook HMAC secret as a separate owner-controlled file.\nNever reuse the API token, signing seed, database credential, or caller token as\nthe webhook secret.\n\n## 4. Prepare durable PostgreSQL\n\nThe standalone host uses PostgreSQL for shared runtime state. One logical\ninstance needs durable access across replica restart and replacement.\n\nPreserve at least:\n\n- Action and idempotency records;\n- execution checkpoints and receipts;\n- connector profile state;\n- webhook replay nonces when ingress is enabled;\n- local event records;\n- durable connector-event outbox batches;\n- registry lease and lifecycle evidence owned by their services.\n\nApply database TLS, least-privilege role, encryption, backup, restore testing,\nmonitoring, and retention policy outside the connector.\n\nDo not deploy a webhook-enabled second replica with an independent replay\ndatabase under the same instance identity. Every replica of one instance must\nshare the profile-state replay scope.\n\n## 5. Isolate network routes\n\nAllow the host to reach only:\n\n- the fixed Twenty origin;\n- its PostgreSQL service;\n- the lifecycle control plane;\n- the trusted AIP gateway path;\n- the configured central event endpoint when webhooks are enabled;\n- required private-PKI services according to deployment policy.\n\nExpose the native AIP endpoint only through authenticated ingress. The public\nendpoint supplied to the host must end in `/aip/v1/messages`.\n\nThe provider origin must be HTTPS unless controlled loopback or explicitly\nallowed private HTTP applies. It contains no credential, path, query, or\nfragment, and provider redirects remain disabled.\n\nIf webhooks are enabled, expose only the deployment-owned external route that\nmaps to internal `POST /webhooks/twenty`. Preserve all required headers and the\nraw body exactly.\n\n## 6. Configure the provider binding\n\nSet the product-specific values together:\n\n```text\nAIP_TWENTY_BASE_URL=https://crm.example.test\nAIP_TWENTY_WORKSPACE_ID=0190c42f-2d5a-7000-8000-000000000090\nAIP_TWENTY_API_TOKEN_FILE=/run/secrets/twenty-api-token\nAIP_TWENTY_OPERATIONS_FILE=/run/config/twenty-operations.json\nAIP_TWENTY_MAX_RESPONSE_BYTES=67108864\n```\n\nOmit the operations file only when all 22 source operations are intentionally\nadmitted. Keep critical metadata and permanent-destroy operations disabled\nuntil policy, procedures, and evidence are ready.\n\nConfigure all common identity, database, signing, gateway, control-plane,\ntopology, artifact, secret-provider, lifecycle, and optional credential-handle\nvalues from one reviewed deployment record.\n\n## 7. Add webhook ingress only when required\n\nFor a webhook-enabled instance, add:\n\n```text\nAIP_TWENTY_WEBHOOK_SECRET_FILE=/run/secrets/twenty-webhook-hmac\nAIP_CONNECTOR_HOST_EVENT_ENDPOINT=https://aipd.example.test/aip/v1/events\n```\n\nConfigure event destination TLS and private-network exceptions through the\nshared host settings. An invalid or unauthorized event route fails startup.\n\nThe host derives replay scope from `instance:<instance_id>`, mounts the webhook\nroute, and declares channel `twenty-webhooks`. Omission of the secret leaves the\nroute unmounted.\n\nProvider webhook metadata is a separate critical mutation. Create it after the\nhost ingress, replay store, local event log, and central outbox are ready.\n\n## 8. Start in dependency order\n\nStart the host only after:\n\n1. the immutable connector version is admitted;\n2. PostgreSQL is reachable through its protected URL file;\n3. lifecycle control plane and gateway trust identities are available;\n4. private TLS roots and fixed provider routing are ready;\n5. all required secret and configuration files are mounted;\n6. the expected provider workspace and least-privilege token are active;\n7. optional event ingress and outbox destination are authorized;\n8. the target instance and replica assignments are provisioned.\n\nDuring preparation, the host validates configuration, opens durable storage,\nconstructs signed identity, and discovers its manifest before registration.\nFailure prevents normal registration and readiness.\n\nDo not bypass an invalid operation suffix, workspace UUID, origin, secret file,\nDID, credential revision, or manifest.\n\n## 9. Gate traffic on health and readiness\n\nUse `/health` for process-level diagnosis. Use `/ready` for route eligibility.\nThe generic image healthcheck probes only loopback `/health`.\n\nThe connector-specific health check sends authenticated\n`GET /rest/open-api/core` to the fixed provider origin. A successful HTTP status\nproves path reachability for that credential at that moment.\n\nBefore tenant traffic, verify:\n\n- running image digest equals the admitted artifact;\n- type, version, instance, replica, tenant, external account, and topology match;\n- credential and configuration revisions match the deployment record;\n- PostgreSQL, lifecycle lease, host health, and host readiness pass;\n- discovered capabilities equal the intended operation subset;\n- unauthorized tenants have no eligible route;\n- a bounded read returns data from the intended workspace;\n- optional webhook route and central event path pass a controlled test.\n\nHealth does not validate every operation, mutation permission, schema, replay\nrace, or event recovery path.\n\n## 10. Scale with shared instance state\n\nMultiple replicas of one logical instance need:\n\n- unique replica IDs and signing identity decisions;\n- the same admitted connector version and compatible configuration;\n- shared durable PostgreSQL for Action and profile state;\n- the same provider workspace and credential policy;\n- one coherent operation allowlist and artifact identity;\n- one instance-scoped webhook replay boundary when ingress is enabled;\n- explicit route weights, zones, capacity, leases, and drain ownership.\n\nDo not scale by copying one replica ID, creating an independent replay database,\nor changing workspace ownership on one replica.\n\nRun multi-replica qualification before claiming cross-replica idempotency,\nwebhook replay, event outbox recovery, or failover behavior for the artifact.\n\n## 11. Replace or roll back safely\n\nDrain the old replica through the lifecycle control plane before removal. Stop\nnew assignments, preserve durable state, and observe in-flight Actions within\nthe configured drain deadline.\n\nBefore replacement, classify every nonterminal or uncertain mutation. Preserve\nthe original Action, key, provider request identity, checkpoint, result, and\nreceipts. Do not replay it to prove the replacement works.\n\nStart a replacement with a new replica ID, the intended immutable image, the\nsame logical instance state, and a reviewed configuration revision. Verify\nhealth, readiness, registry identity, capability subset, and workspace read\nbefore moving assignments.\n\nFor rollback, use a previously admitted immutable artifact whose schema,\ndatabase, operation allowlist, and provider mapping remain compatible. Keep the\nnew replica available only within the explicit rollback window.\n\nRetain retired identities, image digests, registry history, database snapshots,\nwebhook replay and outbox state, checks, drain evidence, and operator decision\nuntil incident and replay-retention obligations close.\n\n## Verify the deployment\n\nAccept deployment state only when:\n\n- immutable host digest and provenance match admission;\n- required files pass ownership, type, size, and secret-custody checks;\n- fixed provider origin, workspace, external account, and credential align;\n- PostgreSQL backup and restore responsibilities are assigned;\n- network policy permits only intended dependencies and ingress;\n- process health and route readiness are independently verified;\n- registry identity and discovered operation subset match the running replica;\n- unauthorized tenant and credential-revision checks fail closed;\n- one bounded read completes with retained evidence;\n- optional webhook delivery is accepted, persisted, and centrally observed;\n- drain, replacement, and rollback preserve original Action and replay state.\n\nThis checklist accepts a deployment configuration. Connector qualification\nstill requires an exact procedure, artifact, provider identity, results, and\nlimitations.\n\n## Related documentation\n\n- [Twenty connector overview](../README.md)\n- [Twenty connector configuration](../reference/configuration.md)\n- [Authentication and workspace isolation](../getting-started/authentication-and-workspace-isolation.md)\n- [Connector host lifecycle](../../../guides/connector-host-lifecycle.md)\n- [Deploy the connector fleet](../../../guides/deploy-connector-fleet.md)\n",
    "text": "Deploy the Twenty connector\n\nUse this procedure to deploy one standalone aip-host-twenty instance. The\nhost owns AIP identity, fixed provider workspace access, durable Action state,\noptional webhook replay, local events, and central publication.\n\nThe reviewed connector-fleet Compose file does not contain a Twenty service.\nUse the source-owned binary and generic host image as inputs to a separately\nreviewed deployment rather than treating that Compose topology as a template.\n\nFix the deployment unit\n\nOne logical instance requires:\n\n| Component | Role | Durable ownership |\n\n| aip-host-twenty | AIP endpoint, provider mapping, health, webhook ingress | Connector runtime PostgreSQL |\n| Twenty deployment | Fixed record and metadata provider | Provider-owned workspace state |\n| Connector control plane | Type, version, instance, replica, lease, lifecycle | Registry and admission state |\n| AIP gateway | Signed tenant traffic and route selection | Gateway runtime state |\n| Private ingress | Host AIP, lifecycle, and optional webhook routes | TLS and routing configuration |\n| Secret manager | Database URL, signing seed, API token, optional webhook secret | Versioned secret material |\n\nThe Twenty provider does not run inside the connector host. Keep its lifecycle,\nbackup, schema, and credential ownership separate from the AIP artifact.\n1. Freeze the host artifact\n\nThe generic host Dockerfile accepts this exact package and binary pair:\n\nPACKAGE=aip-host-twenty\nBINARY=aip-host-twenty\n\nA representative source build is:\n\ndocker build \\\n  --file deploy/connector-fleet/Dockerfile.host \\\n  --build-arg PACKAGE=aip-host-twenty \\\n  --build-arg BINARY=aip-host-twenty \\\n  --build-arg SOURCEREVISION=97be86e9efedf07ecf1783b03800f683f107fb04 \\\n  --build-arg IMAGEVERSION=1.0.0 \\\n  --tag getaip/aip-host-twenty:reviewed \\\n  .\n\nRun this command only from a clean checkout whose exact revision and lockfiles\nhave passed the deployment's build policy. The mutable example tag is not an\nartifact identity.\n\nThe runtime image:\n• uses a pinned Alpine base in source;\n• runs as UID and GID 10001;\n• exposes port 8081;\n• installs the binary as /usr/local/bin/aip-connector-host;\n• uses that binary as its entrypoint;\n• checks loopback /health with wget.\n\nRetain immutable OCI digest, source revision, Cargo lock identity, provenance,\nsoftware bill of materials, vulnerability decision, labels, and build logs.\n\nThe source-owned product image verifier includes aip-host-twenty, checks its\nhelp output, non-root user, entrypoint, component label, revision, and version.\nThat build check is input to deployment review, not runtime qualification.\n2. Admit the artifact and instance\n\nCreate or verify an immutable connector type and version before starting the\nreplica. Bind the version to the exact image digest and required evidence.\n\nProvision unique values for:\n• connector instance ID;\n• connector replica ID;\n• tenant and membership IDs;\n• external-account ID and system;\n• artifact digest and configuration revision;\n• region, zone, capacity class, and trust domain;\n• provider workspace UUID and credential revision.\n\nFor a tenant-owned workspace, deployment policy should require external-account\nID to equal the configured workspace UUID. The host does not enforce that\nequality automatically.\n\nDo not reuse a replica ID for two running processes. Do not change the provider\nworkspace behind an unchanged logical instance without a new admission and\nconfiguration decision.\n3. Provision owner-controlled files\n\nMount these required host inputs:\n\n| Input | Secret | Purpose |\n\n| PostgreSQL URL file | Yes | Durable runtime, replay, event, and outbox stores |\n| Ed25519 signing-seed file | Yes | Host response, lifecycle, and callback identity |\n| Twenty API-token file | Yes | Fixed provider Bearer authentication |\n| Gateway DID file or value | No | Verify signed gateway traffic |\n| Control-plane DID file or value | No | Verify lifecycle responses |\n| Private CA file | No | Validate private deployment TLS when used |\n| Operation allowlist file | No | Non-empty subset of 22 fixed suffixes |\n| Credential-revision policy file | No | Reloadable fail-closed authority fence |\n\nThe database URL and API token have 16 KiB file bounds. The signing seed has a\n256-byte file bound and must encode exactly 32 bytes as hexadecimal. The\noperation file has a 128 KiB bound.\n\nSecret files must be regular, non-symlink, owner-controlled inputs with no group\nor world permission bits on Unix. Mount them read-only to the host.\n\nProvision the optional webhook HMAC secret as a separate owner-controlled file.\nNever reuse the API token, signing seed, database credential, or caller token as\nthe webhook secret.\n4. Prepare durable PostgreSQL\n\nThe standalone host uses PostgreSQL for shared runtime state. One logical\ninstance needs durable access across replica restart and replacement.\n\nPreserve at least:\n• Action and idempotency records;\n• execution checkpoints and receipts;\n• connector profile state;\n• webhook replay nonces when ingress is enabled;\n• local event records;\n• durable connector-event outbox batches;\n• registry lease and lifecycle evidence owned by their services.\n\nApply database TLS, least-privilege role, encryption, backup, restore testing,\nmonitoring, and retention policy outside the connector.\n\nDo not deploy a webhook-enabled second replica with an independent replay\ndatabase under the same instance identity. Every replica of one instance must\nshare the profile-state replay scope.\n5. Isolate network routes\n\nAllow the host to reach only:\n• the fixed Twenty origin;\n• its PostgreSQL service;\n• the lifecycle control plane;\n• the trusted AIP gateway path;\n• the configured central event endpoint when webhooks are enabled;\n• required private-PKI services according to deployment policy.\n\nExpose the native AIP endpoint only through authenticated ingress. The public\nendpoint supplied to the host must end in /aip/v1/messages.\n\nThe provider origin must be HTTPS unless controlled loopback or explicitly\nallowed private HTTP applies. It contains no credential, path, query, or\nfragment, and provider redirects remain disabled.\n\nIf webhooks are enabled, expose only the deployment-owned external route that\nmaps to internal POST /webhooks/twenty. Preserve all required headers and the\nraw body exactly.\n6. Configure the provider binding\n\nSet the product-specific values together:\n\nAIPTWENTYBASEURL=https://crm.example.test\nAIPTWENTYWORKSPACEID=0190c42f-2d5a-7000-8000-000000000090\nAIPTWENTYAPITOKENFILE=/run/secrets/twenty-api-token\nAIPTWENTYOPERATIONSFILE=/run/config/twenty-operations.json\nAIPTWENTYMAXRESPONSEBYTES=67108864\n\nOmit the operations file only when all 22 source operations are intentionally\nadmitted. Keep critical metadata and permanent-destroy operations disabled\nuntil policy, procedures, and evidence are ready.\n\nConfigure all common identity, database, signing, gateway, control-plane,\ntopology, artifact, secret-provider, lifecycle, and optional credential-handle\nvalues from one reviewed deployment record.\n7. Add webhook ingress only when required\n\nFor a webhook-enabled instance, add:\n\nAIPTWENTYWEBHOOKSECRETFILE=/run/secrets/twenty-webhook-hmac\nAIPCONNECTORHOSTEVENTENDPOINT=https://aipd.example.test/aip/v1/events\n\nConfigure event destination TLS and private-network exceptions through the\nshared host settings. An invalid or unauthorized event route fails startup.\n\nThe host derives replay scope from instance:, mounts the webhook\nroute, and declares channel twenty-webhooks. Omission of the secret leaves the\nroute unmounted.\n\nProvider webhook metadata is a separate critical mutation. Create it after the\nhost ingress, replay store, local event log, and central outbox are ready.\n8. Start in dependency order\n\nStart the host only after:\n1. the immutable connector version is admitted;\n2. PostgreSQL is reachable through its protected URL file;\n3. lifecycle control plane and gateway trust identities are available;\n4. private TLS roots and fixed provider routing are ready;\n5. all required secret and configuration files are mounted;\n6. the expected provider workspace and least-privilege token are active;\n7. optional event ingress and outbox destination are authorized;\n8. the target instance and replica assignments are provisioned.\n\nDuring preparation, the host validates configuration, opens durable storage,\nconstructs signed identity, and discovers its manifest before registration.\nFailure prevents normal registration and readiness.\n\nDo not bypass an invalid operation suffix, workspace UUID, origin, secret file,\nDID, credential revision, or manifest.\n9. Gate traffic on health and readiness\n\nUse /health for process-level diagnosis. Use /ready for route eligibility.\nThe generic image healthcheck probes only loopback /health.\n\nThe connector-specific health check sends authenticated\nGET /rest/open-api/core to the fixed provider origin. A successful HTTP status\nproves path reachability for that credential at that moment.\n\nBefore tenant traffic, verify:\n• running image digest equals the admitted artifact;\n• type, version, instance, replica, tenant, external account, and topology match;\n• credential and configuration revisions match the deployment record;\n• PostgreSQL, lifecycle lease, host health, and host readiness pass;\n• discovered capabilities equal the intended operation subset;\n• unauthorized tenants have no eligible route;\n• a bounded read returns data from the intended workspace;\n• optional webhook route and central event path pass a controlled test.\n\nHealth does not validate every operation, mutation permission, schema, replay\nrace, or event recovery path.\n10. Scale with shared instance state\n\nMultiple replicas of one logical instance need:\n• unique replica IDs and signing identity decisions;\n• the same admitted connector version and compatible configuration;\n• shared durable PostgreSQL for Action and profile state;\n• the same provider workspace and credential policy;\n• one coherent operation allowlist and artifact identity;\n• one instance-scoped webhook replay boundary when ingress is enabled;\n• explicit route weights, zones, capacity, leases, and drain ownership.\n\nDo not scale by copying one replica ID, creating an independent replay database,\nor changing workspace ownership on one replica.\n\nRun multi-replica qualification before claiming cross-replica idempotency,\nwebhook replay, event outbox recovery, or failover behavior for the artifact.\n11. Replace or roll back safely\n\nDrain the old replica through the lifecycle control plane before removal. Stop\nnew assignments, preserve durable state, and observe in-flight Actions within\nthe configured drain deadline.\n\nBefore replacement, classify every nonterminal or uncertain mutation. Preserve\nthe original Action, key, provider request identity, checkpoint, result, and\nreceipts. Do not replay it to prove the replacement works.\n\nStart a replacement with a new replica ID, the intended immutable image, the\nsame logical instance state, and a reviewed configuration revision. Verify\nhealth, readiness, registry identity, capability subset, and workspace read\nbefore moving assignments.\n\nFor rollback, use a previously admitted immutable artifact whose schema,\ndatabase, operation allowlist, and provider mapping remain compatible. Keep the\nnew replica available only within the explicit rollback window.\n\nRetain retired identities, image digests, registry history, database snapshots,\nwebhook replay and outbox state, checks, drain evidence, and operator decision\nuntil incident and replay-retention obligations close.\n\nVerify the deployment\n\nAccept deployment state only when:\n• immutable host digest and provenance match admission;\n• required files pass ownership, type, size, and secret-custody checks;\n• fixed provider origin, workspace, external account, and credential align;\n• PostgreSQL backup and restore responsibilities are assigned;\n• network policy permits only intended dependencies and ingress;\n• process health and route readiness are independently verified;\n• registry identity and discovered operation subset match the running replica;\n• unauthorized tenant and credential-revision checks fail closed;\n• one bounded read completes with retained evidence;\n• optional webhook delivery is accepted, persisted, and centrally observed;\n• drain, replacement, and rollback preserve original Action and replay state.\n\nThis checklist accepts a deployment configuration. Connector qualification\nstill requires an exact procedure, artifact, provider identity, results, and\nlimitations.\n\nRelated documentation\n• Twenty connector overview (../README.md)\n• Twenty connector configuration (../reference/configuration.md)\n• Authentication and workspace isolation (../getting-started/authentication-and-workspace-isolation.md)\n• Connector host lifecycle (../../../guides/connector-host-lifecycle.md)\n• Deploy the connector fleet (../../../guides/deploy-connector-fleet.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "621a2b8c266882fefd8f2239a6fbf156c3a6b7cf69267e8bf004f7c40342e35c"
  }
}