{
  "schemaVersion": "1.0",
  "title": "Deploy the Cal.diy connector",
  "description": "Use this guide to deploy one aip-host-cal-diy instance for one Cal.diy account, prove that its admitted identity and provider connection are ready, and introduce it to tenant traffic without creating a second account owner.",
  "canonical": "https://getaip.org/docs/connectors/cal-diy/operations/deployment",
  "route": "/docs/connectors/cal-diy/operations/deployment",
  "source": "docs/connectors/cal-diy/operations/deployment.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/cal-diy/operations/deployment.md",
    "txt": "/docs/download/connectors/cal-diy/operations/deployment.txt",
    "json": "/docs/download/connectors/cal-diy/operations/deployment.json",
    "pdf": "/docs/download/connectors/cal-diy/operations/deployment.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Deploy the Cal.diy connector\ndescription: >-\n  Deploy one admitted Cal.diy standalone host and roll it out without changing\n  its account boundary\nkind: how-to\naudience: operator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: cal-diy\n---\n\n# Deploy the Cal.diy connector\n\nUse this guide to deploy one `aip-host-cal-diy` instance for one Cal.diy\naccount, prove that its admitted identity and provider connection are ready,\nand introduce it to tenant traffic without creating a second account owner.\n\nComplete the common [connector fleet deployment](../../../guides/deploy-connector-fleet.md)\nfirst. This page adds the Cal.diy artifact, account, authentication, network,\nand rollout decisions. It does not turn the repository qualification Compose\nfile into a production topology.\n\n## Preserve the deployment boundary\n\nThe standalone process owns one stable Cal.diy account boundary. Every replica\nof that instance uses the same admitted connector instance, external account,\ncredential policy, and durable runtime state. A replacement process receives a\nnew replica identity; it does not create a second instance for the same account.\n\nApplications send signed actions to product-neutral `aipd`. The gateway routes\nan admitted action to the host's `/aip/v1/messages` endpoint. Applications do\nnot call the host or the Cal.diy API directly.\n\nThe source-owned container image builds package and binary\n`aip-host-cal-diy`, runs as user `10001`, exposes process port `8081`, and has a\ncontainer liveness check on `/health`. Pin the released image by immutable\ndigest. A mutable image tag is not an admission identity.\n\n## 1. Freeze one deployment record\n\nRecord these values before preparing the host or an admission package:\n\n| Value | Cal.diy rule |\n|---|---|\n| Connector type and version | Match the admitted Cal.diy manifest and immutable artifact |\n| Instance ID | Represents one tenant-owned Cal.diy account |\n| Replica ID | Identifies one concrete host process and is never reused concurrently |\n| Tenant and membership | Match the tenant binding admitted for this instance |\n| External account | Set the stable account ID and system `cal_diy` |\n| Public endpoint | End in `/aip/v1/messages` and resolve to this replica |\n| Host identity | Match the pre-provisioned replica DID and signing seed |\n| Artifact digest | Match the bytes running in the container |\n| Configuration revision | Increase when the deployment-owned configuration changes |\n| Credential revision | Identify the credential revision accepted for new assignments |\n\nUse a distinct host signing seed and replica ID for every replica. Keep the\nconnector instance and external account stable across a normal replacement.\nChanging account ownership requires a new reviewed instance boundary.\n\n## 2. Prepare the runtime and network\n\nProvision a durable PostgreSQL database for this connector boundary. Do not use\nthe registry database or container filesystem for runtime state. A replacement\nmust reconnect to the retained database before it can recover work and\nregister.\n\nAllow only the required flows:\n\n| Direction | Peer and route | Purpose |\n|---|---|---|\n| Inbound | `aipd` to `/aip/v1/messages` | Signed manifest-pinned AIP traffic |\n| Inbound, operator network | `/health`, `/ready`, `/metrics`, `/aip/v1/manifest` | Liveness, readiness, metrics, and contract inspection |\n| Inbound, optional | Cal.diy to `/webhooks/cal-diy/{subscription_id}` | Authenticated provider event ingress |\n| Outbound | Connector lifecycle control endpoint | Signed register, heartbeat, drain, and offline transitions |\n| Outbound | Host PostgreSQL | Durable actions, events, profile state, and recovery |\n| Outbound | `AIPD_CAL_DIY_BASE_URL` | Cal.diy API calls and authenticated health probe |\n| Outbound, when configured | Central callback endpoint | Stream callbacks through the pinned route |\n| Outbound, required for webhooks | Central connector-event endpoint | Durable publication of accepted provider events |\n\nTerminate external TLS at a reviewed ingress or service proxy. Pin the gateway\nand lifecycle identities and the required CA roots in the host. Do not expose\nthe observation routes to an untrusted network. Preserve raw webhook request\nbytes and the required signature and version headers through every proxy.\n\n## 3. Stage configuration and secrets\n\nSet the common host contract from\n[Connector host configuration](../../../reference/connector-host-configuration.md).\nThen set the Cal.diy values:\n\n| Setting | Requirement |\n|---|---|\n| `AIPD_CAL_DIY_BASE_URL` | Absolute provider origin owned by this deployment |\n| `AIPD_CAL_DIY_ACCOUNT_ID` | Stable account boundary matching admission |\n| `AIPD_CAL_DIY_BEARER_TOKEN_FILE` | Bearer credential file when bearer authentication is selected |\n| `AIPD_CAL_DIY_OAUTH_CLIENT_ID` | Public client ID when OAuth client credentials are selected |\n| `AIPD_CAL_DIY_OAUTH_CLIENT_SECRET_FILE` | Secret file paired with the OAuth client ID |\n| `AIPD_CAL_DIY_MAX_RESPONSE_BYTES` | Optional positive provider-response limit |\n| `AIPD_CAL_DIY_WEBHOOK_SECRET_FILES` | Optional comma-separated `SUBSCRIPTION_ID=SECRET_FILE` mappings |\n| `AIPD_CAL_DIY_WEBHOOK_SUBSCRIBER_PREFIXES` | Optional approved HTTPS destination prefixes for webhook creation |\n\nSelect exactly one authentication mode: one bearer-token file, or one complete\nOAuth client-ID and client-secret-file pair. The process rejects an incomplete\nor mixed selection before it serves traffic.\n\nMount database URLs, the host signing seed, provider credentials, and webhook\nsecrets as owner-controlled files. Mount public DIDs, CA certificates,\nendpoint data, and the reloadable credential-revision policy separately. Keep\nsecret values out of environment variables, image layers, logs, and admission\npackages.\n\nIf webhook secret mappings are present, configure the central event endpoint.\nThe host refuses to start webhook ingress without its signed event publisher.\nReview the complete ingress contract in\n[Webhook security and replay](../reference/webhook-security-and-replay.md).\n\n## 4. Harden and admit the artifact\n\nRun the container with a read-only root filesystem, user `10001`, all Linux\ncapabilities dropped, `no-new-privileges`, and a small `noexec,nosuid` temporary\nfilesystem. Mount only the state, trust, and secret files required by this\ninstance. These controls mirror the source-owned qualification composition;\nadapt their storage and ingress wiring to the production platform.\n\nVerify the image digest, manifest digest, connector version, and implementation\nsupport map before signing admission. Pre-provision the instance and replica,\nthen apply the first package with the intended tenant capability binding\ndisabled. Do not let a host process create its own registry identity.\n\n## 5. Start and prove readiness\n\nStart the exact admitted artifact. The host performs this sequence before it\nserves AIP traffic:\n\n1. validates common and Cal.diy configuration and reads bounded secret files;\n2. creates the fixed Cal.diy connector and its 81-capability manifest;\n3. opens PostgreSQL and recovers durable runtime state;\n4. constructs optional webhook replay and event-publication state;\n5. verifies storage and the authenticated Cal.diy profile endpoint;\n6. registers the pre-provisioned replica and applies its lifecycle lease;\n7. starts heartbeat renewal and the HTTP server.\n\nUse `/health` only to determine whether the process can answer. The image's\nbuilt-in health check does not prove provider, storage, or lease readiness.\nRequire `/ready` to return success and confirm all four conditions:\n\n- `draining` is false;\n- `lease_valid` is true;\n- `runtime.ready` is true;\n- `connector.ready` is true.\n\nThe Cal.diy connector probe performs an authenticated profile read. A\nsuccessful readiness response therefore proves the configured credential can\nreach that endpoint at that moment. It does not qualify the other 80\ncapabilities or prove that mutations will succeed.\n\nCompare the served manifest and running artifact with the admission record.\nConfirm that the gateway sees the expected replica, endpoint, DID, topology,\nlease, and zero active assignments before enabling discovery.\n\n## 6. Introduce one safe path\n\nApply a higher signed package revision that enables only the reviewed tenant\nbinding. Through the authenticated gateway boundary:\n\n1. confirm that the tenant can discover the intended capability;\n2. confirm that another tenant cannot discover it;\n3. call `cap:cal_diy:profile.get` with a fresh action ID;\n4. retain the route assignment, result, receipts, provider request ID, and\n   redacted host evidence;\n5. verify that the intended Cal.diy account produced the result.\n\nDo not begin with booking, event-type, webhook, or other mutations. Introduce\nthose groups only after their approval, idempotency, compensation, and account\nscope have been reviewed. Follow\n[Authentication and tenant routing](../getting-started/authentication-and-tenant-routing.md)\nfor the caller boundary.\n\n## 7. Roll out a replacement\n\nKeep one logical owner for the Cal.diy account throughout the rollout. If the\nplatform overlaps replicas, they must use distinct replica identities under the\nsame connector instance, the same external account, and shared durable state.\n\nFor a normal replacement:\n\n1. admit the new immutable version and a new replica identity;\n2. start one new replica with the intended binding still controlled;\n3. require registration, manifest parity, a current lease, and `/ready`;\n4. route only the reviewed canary scope supported by the fleet policy;\n5. compare profile-read, error, latency, lease, and provider evidence;\n6. pause new mutations and reconcile every uncertain or pinned action;\n7. terminate the old replica through its normal shutdown signal;\n8. require drain completion and the registry `offline` transition;\n9. expand the new version only after retained evidence passes review.\n\n`SIGTERM` and `Ctrl-C` invoke the source-owned graceful path. The host marks\nitself draining, rejects new actions with `connector_host.not_ready`, waits for\nin-flight work up to the configured drain timeout, stops heartbeat and serving,\nand requests the offline transition. An orchestrator kill timeout must exceed\nthe host drain timeout plus network margin.\n\n## Roll back without losing work\n\nDisable the affected binding in a higher signed package revision before\nrestoring an earlier version. Confirm that new discovery and assignments have\nstopped, but do not assume this cancels provider work already in progress.\n\nReconcile pinned actions and unknown outcomes against the replica that owns\ntheir route. Drain the rejected version normally, require it to become offline,\nand retain its PostgreSQL state, outbox, replay records, logs, and audit\nevidence. Restore the prior immutable artifact and its matching admission and\nconfiguration as one reviewed unit. Never retry an uncertain mutation through\na different replica merely because rollback completed.\n\n## Resolve deployment failures\n\n| Symptom | Decision |\n|---|---|\n| Process exits before registration | Check the exclusive authentication mode, bounded secret files, URLs, identity fields, and webhook event endpoint |\n| Registration is rejected | Compare type, version, instance, replica, tenant, membership, endpoint, DID, artifact digest, manifest digest, and configuration revision with admission |\n| `/health` succeeds and `/ready` fails | Inspect `lease_valid`, `draining`, runtime storage detail, and the authenticated Cal.diy profile probe |\n| Provider probe fails | Verify the provider origin, CA trust, account boundary, selected credential mode, credential revision, and provider availability |\n| Lease expires or heartbeat failures rise | Remove the replica from new traffic and inspect lifecycle reachability, signed control responses, clocks, and registry state |\n| Webhook-enabled host will not start | Require the central event endpoint and validate every `SUBSCRIPTION_ID=SECRET_FILE` mapping |\n| New version returns an unknown mutation outcome | Preserve the pinned route and reconcile before retry, rollback, or credential rotation |\n| Old replica does not become offline | Keep new mutations paused; retain process and lifecycle evidence and follow the fleet recovery procedure |\n\n## Retain deployment evidence\n\nRetain one record containing:\n\n- the source revision plus image and manifest digests;\n- admission package and policy revisions;\n- instance and replica identities, account ID, and public endpoint;\n- host and peer DIDs, configuration and credential revisions, database\n  identity, and network policy;\n- readiness response, lifecycle lease, first safe action, rollout decision,\n  drain result, and offline state.\n\nThis record proves only the observed deployment boundary. It does not prove\nexternal-product qualification, all-capability conformance, exactly-once\nprovider effects, or a zero-downtime rollout.\n\n## Related documentation\n\n- [Deploy the connector fleet](../../../guides/deploy-connector-fleet.md)\n- [Connector host configuration](../../../reference/connector-host-configuration.md)\n- [Connector host lifecycle](../../../guides/connector-host-lifecycle.md)\n- [Cal.diy configuration](../reference/configuration.md)\n- [Cal.diy authentication and tenant\n  routing](../getting-started/authentication-and-tenant-routing.md)\n",
    "text": "Deploy the Cal.diy connector\n\nUse this guide to deploy one aip-host-cal-diy instance for one Cal.diy\naccount, prove that its admitted identity and provider connection are ready,\nand introduce it to tenant traffic without creating a second account owner.\n\nComplete the common connector fleet deployment (../../../guides/deploy-connector-fleet.md)\nfirst. This page adds the Cal.diy artifact, account, authentication, network,\nand rollout decisions. It does not turn the repository qualification Compose\nfile into a production topology.\n\nPreserve the deployment boundary\n\nThe standalone process owns one stable Cal.diy account boundary. Every replica\nof that instance uses the same admitted connector instance, external account,\ncredential policy, and durable runtime state. A replacement process receives a\nnew replica identity; it does not create a second instance for the same account.\n\nApplications send signed actions to product-neutral aipd. The gateway routes\nan admitted action to the host's /aip/v1/messages endpoint. Applications do\nnot call the host or the Cal.diy API directly.\n\nThe source-owned container image builds package and binary\naip-host-cal-diy, runs as user 10001, exposes process port 8081, and has a\ncontainer liveness check on /health. Pin the released image by immutable\ndigest. A mutable image tag is not an admission identity.\n1. Freeze one deployment record\n\nRecord these values before preparing the host or an admission package:\n\n| Value | Cal.diy rule |\n\n| Connector type and version | Match the admitted Cal.diy manifest and immutable artifact |\n| Instance ID | Represents one tenant-owned Cal.diy account |\n| Replica ID | Identifies one concrete host process and is never reused concurrently |\n| Tenant and membership | Match the tenant binding admitted for this instance |\n| External account | Set the stable account ID and system caldiy |\n| Public endpoint | End in /aip/v1/messages and resolve to this replica |\n| Host identity | Match the pre-provisioned replica DID and signing seed |\n| Artifact digest | Match the bytes running in the container |\n| Configuration revision | Increase when the deployment-owned configuration changes |\n| Credential revision | Identify the credential revision accepted for new assignments |\n\nUse a distinct host signing seed and replica ID for every replica. Keep the\nconnector instance and external account stable across a normal replacement.\nChanging account ownership requires a new reviewed instance boundary.\n2. Prepare the runtime and network\n\nProvision a durable PostgreSQL database for this connector boundary. Do not use\nthe registry database or container filesystem for runtime state. A replacement\nmust reconnect to the retained database before it can recover work and\nregister.\n\nAllow only the required flows:\n\n| Direction | Peer and route | Purpose |\n\n| Inbound | aipd to /aip/v1/messages | Signed manifest-pinned AIP traffic |\n| Inbound, operator network | /health, /ready, /metrics, /aip/v1/manifest | Liveness, readiness, metrics, and contract inspection |\n| Inbound, optional | Cal.diy to /webhooks/cal-diy/{subscriptionid} | Authenticated provider event ingress |\n| Outbound | Connector lifecycle control endpoint | Signed register, heartbeat, drain, and offline transitions |\n| Outbound | Host PostgreSQL | Durable actions, events, profile state, and recovery |\n| Outbound | AIPDCALDIYBASEURL | Cal.diy API calls and authenticated health probe |\n| Outbound, when configured | Central callback endpoint | Stream callbacks through the pinned route |\n| Outbound, required for webhooks | Central connector-event endpoint | Durable publication of accepted provider events |\n\nTerminate external TLS at a reviewed ingress or service proxy. Pin the gateway\nand lifecycle identities and the required CA roots in the host. Do not expose\nthe observation routes to an untrusted network. Preserve raw webhook request\nbytes and the required signature and version headers through every proxy.\n3. Stage configuration and secrets\n\nSet the common host contract from\nConnector host configuration (../../../reference/connector-host-configuration.md).\nThen set the Cal.diy values:\n\n| Setting | Requirement |\n\n| AIPDCALDIYBASEURL | Absolute provider origin owned by this deployment |\n| AIPDCALDIYACCOUNTID | Stable account boundary matching admission |\n| AIPDCALDIYBEARERTOKENFILE | Bearer credential file when bearer authentication is selected |\n| AIPDCALDIYOAUTHCLIENTID | Public client ID when OAuth client credentials are selected |\n| AIPDCALDIYOAUTHCLIENTSECRETFILE | Secret file paired with the OAuth client ID |\n| AIPDCALDIYMAXRESPONSEBYTES | Optional positive provider-response limit |\n| AIPDCALDIYWEBHOOKSECRETFILES | Optional comma-separated SUBSCRIPTIONID=SECRETFILE mappings |\n| AIPDCALDIYWEBHOOKSUBSCRIBERPREFIXES | Optional approved HTTPS destination prefixes for webhook creation |\n\nSelect exactly one authentication mode: one bearer-token file, or one complete\nOAuth client-ID and client-secret-file pair. The process rejects an incomplete\nor mixed selection before it serves traffic.\n\nMount database URLs, the host signing seed, provider credentials, and webhook\nsecrets as owner-controlled files. Mount public DIDs, CA certificates,\nendpoint data, and the reloadable credential-revision policy separately. Keep\nsecret values out of environment variables, image layers, logs, and admission\npackages.\n\nIf webhook secret mappings are present, configure the central event endpoint.\nThe host refuses to start webhook ingress without its signed event publisher.\nReview the complete ingress contract in\nWebhook security and replay (../reference/webhook-security-and-replay.md).\n4. Harden and admit the artifact\n\nRun the container with a read-only root filesystem, user 10001, all Linux\ncapabilities dropped, no-new-privileges, and a small noexec,nosuid temporary\nfilesystem. Mount only the state, trust, and secret files required by this\ninstance. These controls mirror the source-owned qualification composition;\nadapt their storage and ingress wiring to the production platform.\n\nVerify the image digest, manifest digest, connector version, and implementation\nsupport map before signing admission. Pre-provision the instance and replica,\nthen apply the first package with the intended tenant capability binding\ndisabled. Do not let a host process create its own registry identity.\n5. Start and prove readiness\n\nStart the exact admitted artifact. The host performs this sequence before it\nserves AIP traffic:\n1. validates common and Cal.diy configuration and reads bounded secret files;\n2. creates the fixed Cal.diy connector and its 81-capability manifest;\n3. opens PostgreSQL and recovers durable runtime state;\n4. constructs optional webhook replay and event-publication state;\n5. verifies storage and the authenticated Cal.diy profile endpoint;\n6. registers the pre-provisioned replica and applies its lifecycle lease;\n7. starts heartbeat renewal and the HTTP server.\n\nUse /health only to determine whether the process can answer. The image's\nbuilt-in health check does not prove provider, storage, or lease readiness.\nRequire /ready to return success and confirm all four conditions:\n• draining is false;\n• leasevalid is true;\n• runtime.ready is true;\n• connector.ready is true.\n\nThe Cal.diy connector probe performs an authenticated profile read. A\nsuccessful readiness response therefore proves the configured credential can\nreach that endpoint at that moment. It does not qualify the other 80\ncapabilities or prove that mutations will succeed.\n\nCompare the served manifest and running artifact with the admission record.\nConfirm that the gateway sees the expected replica, endpoint, DID, topology,\nlease, and zero active assignments before enabling discovery.\n6. Introduce one safe path\n\nApply a higher signed package revision that enables only the reviewed tenant\nbinding. Through the authenticated gateway boundary:\n1. confirm that the tenant can discover the intended capability;\n2. confirm that another tenant cannot discover it;\n3. call cap:caldiy:profile.get with a fresh action ID;\n4. retain the route assignment, result, receipts, provider request ID, and\n   redacted host evidence;\n5. verify that the intended Cal.diy account produced the result.\n\nDo not begin with booking, event-type, webhook, or other mutations. Introduce\nthose groups only after their approval, idempotency, compensation, and account\nscope have been reviewed. Follow\nAuthentication and tenant routing (../getting-started/authentication-and-tenant-routing.md)\nfor the caller boundary.\n7. Roll out a replacement\n\nKeep one logical owner for the Cal.diy account throughout the rollout. If the\nplatform overlaps replicas, they must use distinct replica identities under the\nsame connector instance, the same external account, and shared durable state.\n\nFor a normal replacement:\n1. admit the new immutable version and a new replica identity;\n2. start one new replica with the intended binding still controlled;\n3. require registration, manifest parity, a current lease, and /ready;\n4. route only the reviewed canary scope supported by the fleet policy;\n5. compare profile-read, error, latency, lease, and provider evidence;\n6. pause new mutations and reconcile every uncertain or pinned action;\n7. terminate the old replica through its normal shutdown signal;\n8. require drain completion and the registry offline transition;\n9. expand the new version only after retained evidence passes review.\n\nSIGTERM and Ctrl-C invoke the source-owned graceful path. The host marks\nitself draining, rejects new actions with connectorhost.notready, waits for\nin-flight work up to the configured drain timeout, stops heartbeat and serving,\nand requests the offline transition. An orchestrator kill timeout must exceed\nthe host drain timeout plus network margin.\n\nRoll back without losing work\n\nDisable the affected binding in a higher signed package revision before\nrestoring an earlier version. Confirm that new discovery and assignments have\nstopped, but do not assume this cancels provider work already in progress.\n\nReconcile pinned actions and unknown outcomes against the replica that owns\ntheir route. Drain the rejected version normally, require it to become offline,\nand retain its PostgreSQL state, outbox, replay records, logs, and audit\nevidence. Restore the prior immutable artifact and its matching admission and\nconfiguration as one reviewed unit. Never retry an uncertain mutation through\na different replica merely because rollback completed.\n\nResolve deployment failures\n\n| Symptom | Decision |\n\n| Process exits before registration | Check the exclusive authentication mode, bounded secret files, URLs, identity fields, and webhook event endpoint |\n| Registration is rejected | Compare type, version, instance, replica, tenant, membership, endpoint, DID, artifact digest, manifest digest, and configuration revision with admission |\n| /health succeeds and /ready fails | Inspect leasevalid, draining, runtime storage detail, and the authenticated Cal.diy profile probe |\n| Provider probe fails | Verify the provider origin, CA trust, account boundary, selected credential mode, credential revision, and provider availability |\n| Lease expires or heartbeat failures rise | Remove the replica from new traffic and inspect lifecycle reachability, signed control responses, clocks, and registry state |\n| Webhook-enabled host will not start | Require the central event endpoint and validate every SUBSCRIPTIONID=SECRETFILE mapping |\n| New version returns an unknown mutation outcome | Preserve the pinned route and reconcile before retry, rollback, or credential rotation |\n| Old replica does not become offline | Keep new mutations paused; retain process and lifecycle evidence and follow the fleet recovery procedure |\n\nRetain deployment evidence\n\nRetain one record containing:\n• the source revision plus image and manifest digests;\n• admission package and policy revisions;\n• instance and replica identities, account ID, and public endpoint;\n• host and peer DIDs, configuration and credential revisions, database\n  identity, and network policy;\n• readiness response, lifecycle lease, first safe action, rollout decision,\n  drain result, and offline state.\n\nThis record proves only the observed deployment boundary. It does not prove\nexternal-product qualification, all-capability conformance, exactly-once\nprovider effects, or a zero-downtime rollout.\n\nRelated documentation\n• Deploy the connector fleet (../../../guides/deploy-connector-fleet.md)\n• Connector host configuration (../../../reference/connector-host-configuration.md)\n• Connector host lifecycle (../../../guides/connector-host-lifecycle.md)\n• Cal.diy configuration (../reference/configuration.md)\n• Cal.diy authentication and tenant\n  routing (../getting-started/authentication-and-tenant-routing.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "fa83b3dabcade91ed119e13522b21c7d6bf1f2b61bcfca2bb3d24fdcb8f23b44"
  }
}