{
  "schemaVersion": "1.0",
  "title": "Manage Twenty views, layouts, and webhook metadata",
  "description": "Use this guide to change one view, page-layout hierarchy, or provider webhook registration. Begin with the current workspace metadata schema and dependency graph, submit one critical mutation, then verify the provider result through a separ",
  "canonical": "https://getaip.org/docs/connectors/twenty/guides/manage-views-layouts-and-webhook-metadata",
  "route": "/docs/connectors/twenty/guides/manage-views-layouts-and-webhook-metadata",
  "source": "docs/connectors/twenty/guides/manage-views-layouts-and-webhook-metadata.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/twenty/guides/manage-views-layouts-and-webhook-metadata.md",
    "txt": "/docs/download/connectors/twenty/guides/manage-views-layouts-and-webhook-metadata.txt",
    "json": "/docs/download/connectors/twenty/guides/manage-views-layouts-and-webhook-metadata.json",
    "pdf": "/docs/download/connectors/twenty/guides/manage-views-layouts-and-webhook-metadata.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Manage Twenty views, layouts, and webhook metadata\ndescription: >-\n  Snapshot metadata dependencies, apply one governed change, and verify views,\n  layouts, or host-secret-backed webhook registration\nkind: how-to\naudience: integrator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: twenty\n---\n\n# Manage Twenty views, layouts, and webhook metadata\n\nUse this guide to change one view, page-layout hierarchy, or provider webhook\nregistration. Begin with the current workspace metadata schema and dependency\ngraph, submit one critical mutation, then verify the provider result through a\nseparate read.\n\nThe connector validates the selected resource, outer input, parent query, and\nwebhook-secret boundary. Twenty owns resource-specific body fields,\nrelationships, cascades, and the resulting user experience.\n\n## Prerequisites\n\nRequire:\n\n- an admitted Twenty host bound to the intended tenant and workspace;\n- authenticated access to metadata OpenAPI and the needed metadata operations;\n- an integrator who owns the affected object, view, layout, or webhook;\n- a trusted tenant approver for critical metadata changes;\n- a current provider backup or recovery plan for the affected metadata;\n- a durable place for schema, dependency, Action, approval, and result evidence;\n- coordinated host and provider ownership for webhook registration or rotation.\n\nSet only AIP client coordinates:\n\n```sh\nexport AIP_URL='https://aip.example.com'\nexport AIP_TOKEN_FILE='/run/secrets/aip-native-token'\n```\n\nProvider credentials and webhook secret bytes remain host-owned.\n\n## 1. Confirm the admitted operations\n\nDiscover the metadata Resources and Tools used by the intended change:\n\n```sh\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  capability list \"$AIP_URL\" \\\n  --capability-id cap:twenty:openapi.metadata \\\n  --limit 1\n\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  capability list \"$AIP_URL\" \\\n  --capability-id cap:twenty:metadata.list \\\n  --limit 1\n\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  capability list \"$AIP_URL\" \\\n  --capability-id cap:twenty:metadata.update \\\n  --limit 1\n```\n\nUse `metadata.create` or `metadata.delete` instead of update when that is the\nactual intent. Record catalog revision and every selected contract and schema\ndigest.\n\nStop when an operation is absent. Do not widen the host allowlist during an\nactive change merely to satisfy the procedure.\n\n## 2. Capture the metadata schema\n\nRead `cap:twenty:openapi.metadata` with `{}`. Retain the body under\ntenant-scoped controls and calculate its digest outside the connector.\n\nRecord connector artifact, pinned provider mapping, instance, tenant,\nworkspace, credential revision, Action ID, observation time, HTTP status, and\nprovider request ID.\n\nExtract only the provider fields needed for the chosen resource. Freeze their\nrequired status, types, enums, identifiers, parent references, and delete\nbehavior as the change's body contract.\n\nThe connector accepts an arbitrary object body with at most 2,048 top-level\nproperties. It does not validate that body against the observed provider\ndocument.\n\n## 3. Snapshot the current dependency graph\n\nUse `metadata.list` and `metadata.get` before any mutation. The exact reads\ndepend on the resource family.\n\n### Snapshot a view\n\nStart with the owning object and view:\n\n```json\n{\n  \"resource\": \"views\",\n  \"query\": {\n    \"objectMetadataId\": \"0190c42f-2d5a-7000-8000-000000000070\"\n  }\n}\n```\n\nFor each selected view, list these children using its UUID as `viewId`:\n\n- `viewFields`;\n- `viewFilters`;\n- `viewGroups`;\n- `viewSorts`;\n- `viewFilterGroups`.\n\nThe connector permits an omitted `viewId`, but a change review should retain a\nbounded parent-specific snapshot.\n\n### Snapshot a page-layout hierarchy\n\nList layouts by object and optional type:\n\n```json\n{\n  \"resource\": \"pageLayouts\",\n  \"query\": {\n    \"objectMetadataId\": \"0190c42f-2d5a-7000-8000-000000000070\",\n    \"pageLayoutType\": \"RECORD_PAGE\"\n  }\n}\n```\n\nAllowed types are `RECORD_INDEX`, `RECORD_PAGE`, `DASHBOARD`, and\n`STANDALONE_PAGE`. The connector rejects a type without `objectMetadataId`.\n\nList tabs under one layout:\n\n```json\n{\n  \"resource\": \"pageLayoutTabs\",\n  \"query\": {\n    \"pageLayoutId\": \"0190c42f-2d5a-7000-8000-000000000071\"\n  }\n}\n```\n\nThen list widgets under each tab:\n\n```json\n{\n  \"resource\": \"pageLayoutWidgets\",\n  \"query\": {\n    \"pageLayoutTabId\": \"0190c42f-2d5a-7000-8000-000000000072\"\n  }\n}\n```\n\nBoth parent queries are mandatory and UUID-validated. Retain ordered child IDs\nand the fields that the planned body can change.\n\n### Snapshot webhook registrations\n\nList `webhooks` with no query object. The connector rejects any query key for\nthis resource and recursively removes every result field named `secret`.\n\nRecord registration IDs, target ownership, event selection, enabled state, and\nprovider fields exposed by the current metadata document. Do not infer the\nconfigured secret from the redacted result.\n\n## 4. Define one metadata intent\n\nChoose exactly one operation and resource:\n\n| Intent | Capability | Required connector input |\n|---|---|---|\n| Add one resource | `metadata.create` | `resource`, provider-validated object `body` |\n| Change one resource | `metadata.update` | `resource`, resource UUID, provider-validated object `body` |\n| Remove one resource | `metadata.delete` | `resource`, resource UUID |\n\nWrite the complete Action input from the frozen provider body contract. Retain\nits canonical hash and the expected before and after values.\n\nApproval evidence should include:\n\n- schema digest and resource body contract;\n- parent and child IDs;\n- current dependency snapshot;\n- expected UI, automation, routing, and event effects;\n- rollback or restoration procedure outside the connector;\n- target tenant, workspace, credential, and configuration revisions.\n\nThe connector provides no dependency analysis or metadata transaction. Split\nmultiple resources into ordered, independently verifiable intents.\n\n## 5. Submit one governed change\n\nReserve a stable Action ID and external-account-scoped key:\n\n```sh\nexport CAPABILITY='cap:twenty:metadata.update'\nexport INPUT_FILE='metadata-update.json'\nexport ACTION_ID='act_twenty_metadata_update_001'\nexport IDEMPOTENCY_KEY='twenty-metadata-update-v1'\n```\n\nSubmit once:\n\n```sh\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  action call \"$AIP_URL\" \\\n  \"$CAPABILITY\" \\\n  --action-id \"$ACTION_ID\" \\\n  --idempotency-key \"$IDEMPOTENCY_KEY\" \\\n  --mode sync \\\n  --input @\"$INPUT_FILE\"\n```\n\nWithout admitted authorization, the Action enters `requires_human`. Approval\nmust bind the exact resource, ID, body, schema and dependency evidence, policy\nhash, workspace, and intended effect.\n\nApproval resumes the same queued Action. Do not replace the Action or key while\nthe original remains pending.\n\nAll metadata mutations advertise unsafe retry. A key is required for ownership\nand collision control, not automatic replay.\n\n## 6. Apply the webhook-secret rules\n\nSkip this section for non-webhook resources.\n\n### Create a provider registration\n\nThe create input must use `resource: webhooks`. Its body must omit both\n`secret` and `rotateConfiguredSecret`.\n\nThe connector injects the secret configured by\n`AIP_TWENTY_WEBHOOK_SECRET_FILE`. Create fails when host webhook security is not\nconfigured.\n\nThe host exposes `/webhooks/twenty` only when the webhook secret is present. It\nalso requires an authorized `AIP_CONNECTOR_HOST_EVENT_ENDPOINT` for central\nevent delivery.\n\nThe provider target URL, public ingress, TLS, routing, and secret file must\ndescribe the same controlled deployment. Registration creation alone does not\nprove that ingress or publication works.\n\n### Rotate a provider registration\n\nUse `metadata.update` for the exact webhook UUID. The body may include only\nthis connector control when requesting host-secret injection:\n\n```json\n{\n  \"resource\": \"webhooks\",\n  \"id\": \"0190c42f-2d5a-7000-8000-000000000073\",\n  \"body\": {\n    \"rotateConfiguredSecret\": true\n  }\n}\n```\n\nThe connector removes `rotateConfiguredSecret` and injects the current\nhost-owned secret. A caller-supplied `secret`, Boolean `false`, or another value\nis invalid.\n\nProvider update and host secret rollout are not atomic. Use a deployment-owned\ncutover plan that defines old and new ingress ownership, validation, rollback,\nand the point at which the old secret is revoked.\n\nNever place either secret value in Action input, approval evidence, logs, or a\nread-back comparison.\n\n## 7. Read the durable mutation result\n\nRead the original Action:\n\n```sh\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  action status \"$AIP_URL\" \\\n  \"$ACTION_ID\" \\\n  --include-result \\\n  --include-receipts \\\n  --wait-ms 30000\n```\n\nProceed only after terminal `completed`. Retain provider HTTP status, request\nID, decoded redacted body, approval, and receipts.\n\nFor webhook metadata, every response field named `secret` is recursively\nremoved. Absence of a secret in the result is expected and is not proof of a\nprovider mismatch.\n\n## 8. Verify the provider state\n\nUse `metadata.get` on the validated result ID or the original update target.\nFor a create whose result lacks a usable ID, perform a bounded parent-specific\nlist and stop if the created resource cannot be uniquely identified.\n\nCompare only reviewed fields from the frozen body contract. Re-list the\naffected parent children and confirm that unrelated IDs and ordering remain as\nexpected.\n\nFor a delete, verify absence and re-read each known parent or dependent set.\nThe connector does not state whether the provider cascades related resources.\n\nFor a webhook registration, also run a controlled signed delivery through the\ndeployment ingress and verify durable AIP event publication. Metadata read-back\nalone does not exercise signature, replay, storage, or central delivery.\n\n## Recover without replaying a critical mutation\n\n| Observation | Response |\n|---|---|\n| Action is `requires_human` | Complete the original approval workflow |\n| Action remains pending | Read the same Action and receipts |\n| Definitive provider rejection | Refresh metadata schema and dependencies before a new intent |\n| Temporary or transport failure | Preserve Action and key; inspect provider metadata before another write |\n| Invalid or oversized provider response | Treat mutation outcome as uncertain and verify current state |\n| Resource cannot be identified | Stop; do not guess an ID or repeat create |\n| Read-back differs | Classify provider validation, automation, concurrency, or schema drift |\n| Webhook metadata matches but delivery fails | Preserve registration and inspect ingress, signature, replay, storage, and publication separately |\n\nThe connector exposes no rollback or reconciliation operation. A recovery\nchange is a new critical intent with current schema, dependency, approval, and\nidempotency evidence.\n\n## Retain the change evidence\n\nKeep:\n\n- connector, artifact, provider mapping, tenant, workspace, and credential identities;\n- catalog revision and selected capability digests;\n- metadata OpenAPI digest and frozen body contract;\n- bounded before-state and dependency snapshot;\n- Action input hash, Action ID, key, approval, and policy hash;\n- terminal result, receipts, and provider request ID;\n- read-back and dependent-set comparison;\n- for webhooks, redacted registration and separate signed-delivery evidence;\n- recovery or rollback actions as independent chains.\n\nThis evidence supports one controlled metadata change. It does not establish\ngeneral provider compatibility, atomic metadata migration, or qualification of\nanother artifact or workspace.\n\n## Related documentation\n\n- [Twenty workspace metadata](../capabilities/workspace-metadata.md)\n- [Twenty OpenAPI documents](../capabilities/openapi-documents.md)\n- [Manage standard and custom records](manage-standard-and-custom-records.md)\n- [Twenty connector configuration](../reference/configuration.md)\n- [Approvals and policy](../../../concepts/approvals-and-policy.md)\n",
    "text": "Manage Twenty views, layouts, and webhook metadata\n\nUse this guide to change one view, page-layout hierarchy, or provider webhook\nregistration. Begin with the current workspace metadata schema and dependency\ngraph, submit one critical mutation, then verify the provider result through a\nseparate read.\n\nThe connector validates the selected resource, outer input, parent query, and\nwebhook-secret boundary. Twenty owns resource-specific body fields,\nrelationships, cascades, and the resulting user experience.\n\nPrerequisites\n\nRequire:\n• an admitted Twenty host bound to the intended tenant and workspace;\n• authenticated access to metadata OpenAPI and the needed metadata operations;\n• an integrator who owns the affected object, view, layout, or webhook;\n• a trusted tenant approver for critical metadata changes;\n• a current provider backup or recovery plan for the affected metadata;\n• a durable place for schema, dependency, Action, approval, and result evidence;\n• coordinated host and provider ownership for webhook registration or rotation.\n\nSet only AIP client coordinates:\n\nexport AIPURL='https://aip.example.com'\nexport AIPTOKENFILE='/run/secrets/aip-native-token'\n\nProvider credentials and webhook secret bytes remain host-owned.\n1. Confirm the admitted operations\n\nDiscover the metadata Resources and Tools used by the intended change:\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  capability list \"$AIPURL\" \\\n  --capability-id cap:twenty:openapi.metadata \\\n  --limit 1\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  capability list \"$AIPURL\" \\\n  --capability-id cap:twenty:metadata.list \\\n  --limit 1\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  capability list \"$AIPURL\" \\\n  --capability-id cap:twenty:metadata.update \\\n  --limit 1\n\nUse metadata.create or metadata.delete instead of update when that is the\nactual intent. Record catalog revision and every selected contract and schema\ndigest.\n\nStop when an operation is absent. Do not widen the host allowlist during an\nactive change merely to satisfy the procedure.\n2. Capture the metadata schema\n\nRead cap:twenty:openapi.metadata with {}. Retain the body under\ntenant-scoped controls and calculate its digest outside the connector.\n\nRecord connector artifact, pinned provider mapping, instance, tenant,\nworkspace, credential revision, Action ID, observation time, HTTP status, and\nprovider request ID.\n\nExtract only the provider fields needed for the chosen resource. Freeze their\nrequired status, types, enums, identifiers, parent references, and delete\nbehavior as the change's body contract.\n\nThe connector accepts an arbitrary object body with at most 2,048 top-level\nproperties. It does not validate that body against the observed provider\ndocument.\n3. Snapshot the current dependency graph\n\nUse metadata.list and metadata.get before any mutation. The exact reads\ndepend on the resource family.\n\nSnapshot a view\n\nStart with the owning object and view:\n\n{\n  \"resource\": \"views\",\n  \"query\": {\n    \"objectMetadataId\": \"0190c42f-2d5a-7000-8000-000000000070\"\n  }\n}\n\nFor each selected view, list these children using its UUID as viewId:\n• viewFields;\n• viewFilters;\n• viewGroups;\n• viewSorts;\n• viewFilterGroups.\n\nThe connector permits an omitted viewId, but a change review should retain a\nbounded parent-specific snapshot.\n\nSnapshot a page-layout hierarchy\n\nList layouts by object and optional type:\n\n{\n  \"resource\": \"pageLayouts\",\n  \"query\": {\n    \"objectMetadataId\": \"0190c42f-2d5a-7000-8000-000000000070\",\n    \"pageLayoutType\": \"RECORDPAGE\"\n  }\n}\n\nAllowed types are RECORDINDEX, RECORDPAGE, DASHBOARD, and\nSTANDALONEPAGE. The connector rejects a type without objectMetadataId.\n\nList tabs under one layout:\n\n{\n  \"resource\": \"pageLayoutTabs\",\n  \"query\": {\n    \"pageLayoutId\": \"0190c42f-2d5a-7000-8000-000000000071\"\n  }\n}\n\nThen list widgets under each tab:\n\n{\n  \"resource\": \"pageLayoutWidgets\",\n  \"query\": {\n    \"pageLayoutTabId\": \"0190c42f-2d5a-7000-8000-000000000072\"\n  }\n}\n\nBoth parent queries are mandatory and UUID-validated. Retain ordered child IDs\nand the fields that the planned body can change.\n\nSnapshot webhook registrations\n\nList webhooks with no query object. The connector rejects any query key for\nthis resource and recursively removes every result field named secret.\n\nRecord registration IDs, target ownership, event selection, enabled state, and\nprovider fields exposed by the current metadata document. Do not infer the\nconfigured secret from the redacted result.\n4. Define one metadata intent\n\nChoose exactly one operation and resource:\n\n| Intent | Capability | Required connector input |\n\n| Add one resource | metadata.create | resource, provider-validated object body |\n| Change one resource | metadata.update | resource, resource UUID, provider-validated object body |\n| Remove one resource | metadata.delete | resource, resource UUID |\n\nWrite the complete Action input from the frozen provider body contract. Retain\nits canonical hash and the expected before and after values.\n\nApproval evidence should include:\n• schema digest and resource body contract;\n• parent and child IDs;\n• current dependency snapshot;\n• expected UI, automation, routing, and event effects;\n• rollback or restoration procedure outside the connector;\n• target tenant, workspace, credential, and configuration revisions.\n\nThe connector provides no dependency analysis or metadata transaction. Split\nmultiple resources into ordered, independently verifiable intents.\n5. Submit one governed change\n\nReserve a stable Action ID and external-account-scoped key:\n\nexport CAPABILITY='cap:twenty:metadata.update'\nexport INPUTFILE='metadata-update.json'\nexport ACTIONID='acttwentymetadataupdate001'\nexport IDEMPOTENCYKEY='twenty-metadata-update-v1'\n\nSubmit once:\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  action call \"$AIPURL\" \\\n  \"$CAPABILITY\" \\\n  --action-id \"$ACTIONID\" \\\n  --idempotency-key \"$IDEMPOTENCYKEY\" \\\n  --mode sync \\\n  --input @\"$INPUTFILE\"\n\nWithout admitted authorization, the Action enters requireshuman. Approval\nmust bind the exact resource, ID, body, schema and dependency evidence, policy\nhash, workspace, and intended effect.\n\nApproval resumes the same queued Action. Do not replace the Action or key while\nthe original remains pending.\n\nAll metadata mutations advertise unsafe retry. A key is required for ownership\nand collision control, not automatic replay.\n6. Apply the webhook-secret rules\n\nSkip this section for non-webhook resources.\n\nCreate a provider registration\n\nThe create input must use resource: webhooks. Its body must omit both\nsecret and rotateConfiguredSecret.\n\nThe connector injects the secret configured by\nAIPTWENTYWEBHOOKSECRETFILE. Create fails when host webhook security is not\nconfigured.\n\nThe host exposes /webhooks/twenty only when the webhook secret is present. It\nalso requires an authorized AIPCONNECTORHOSTEVENTENDPOINT for central\nevent delivery.\n\nThe provider target URL, public ingress, TLS, routing, and secret file must\ndescribe the same controlled deployment. Registration creation alone does not\nprove that ingress or publication works.\n\nRotate a provider registration\n\nUse metadata.update for the exact webhook UUID. The body may include only\nthis connector control when requesting host-secret injection:\n\n{\n  \"resource\": \"webhooks\",\n  \"id\": \"0190c42f-2d5a-7000-8000-000000000073\",\n  \"body\": {\n    \"rotateConfiguredSecret\": true\n  }\n}\n\nThe connector removes rotateConfiguredSecret and injects the current\nhost-owned secret. A caller-supplied secret, Boolean false, or another value\nis invalid.\n\nProvider update and host secret rollout are not atomic. Use a deployment-owned\ncutover plan that defines old and new ingress ownership, validation, rollback,\nand the point at which the old secret is revoked.\n\nNever place either secret value in Action input, approval evidence, logs, or a\nread-back comparison.\n7. Read the durable mutation result\n\nRead the original Action:\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  action status \"$AIPURL\" \\\n  \"$ACTIONID\" \\\n  --include-result \\\n  --include-receipts \\\n  --wait-ms 30000\n\nProceed only after terminal completed. Retain provider HTTP status, request\nID, decoded redacted body, approval, and receipts.\n\nFor webhook metadata, every response field named secret is recursively\nremoved. Absence of a secret in the result is expected and is not proof of a\nprovider mismatch.\n8. Verify the provider state\n\nUse metadata.get on the validated result ID or the original update target.\nFor a create whose result lacks a usable ID, perform a bounded parent-specific\nlist and stop if the created resource cannot be uniquely identified.\n\nCompare only reviewed fields from the frozen body contract. Re-list the\naffected parent children and confirm that unrelated IDs and ordering remain as\nexpected.\n\nFor a delete, verify absence and re-read each known parent or dependent set.\nThe connector does not state whether the provider cascades related resources.\n\nFor a webhook registration, also run a controlled signed delivery through the\ndeployment ingress and verify durable AIP event publication. Metadata read-back\nalone does not exercise signature, replay, storage, or central delivery.\n\nRecover without replaying a critical mutation\n\n| Observation | Response |\n\n| Action is requireshuman | Complete the original approval workflow |\n| Action remains pending | Read the same Action and receipts |\n| Definitive provider rejection | Refresh metadata schema and dependencies before a new intent |\n| Temporary or transport failure | Preserve Action and key; inspect provider metadata before another write |\n| Invalid or oversized provider response | Treat mutation outcome as uncertain and verify current state |\n| Resource cannot be identified | Stop; do not guess an ID or repeat create |\n| Read-back differs | Classify provider validation, automation, concurrency, or schema drift |\n| Webhook metadata matches but delivery fails | Preserve registration and inspect ingress, signature, replay, storage, and publication separately |\n\nThe connector exposes no rollback or reconciliation operation. A recovery\nchange is a new critical intent with current schema, dependency, approval, and\nidempotency evidence.\n\nRetain the change evidence\n\nKeep:\n• connector, artifact, provider mapping, tenant, workspace, and credential identities;\n• catalog revision and selected capability digests;\n• metadata OpenAPI digest and frozen body contract;\n• bounded before-state and dependency snapshot;\n• Action input hash, Action ID, key, approval, and policy hash;\n• terminal result, receipts, and provider request ID;\n• read-back and dependent-set comparison;\n• for webhooks, redacted registration and separate signed-delivery evidence;\n• recovery or rollback actions as independent chains.\n\nThis evidence supports one controlled metadata change. It does not establish\ngeneral provider compatibility, atomic metadata migration, or qualification of\nanother artifact or workspace.\n\nRelated documentation\n• Twenty workspace metadata (../capabilities/workspace-metadata.md)\n• Twenty OpenAPI documents (../capabilities/openapi-documents.md)\n• Manage standard and custom records (manage-standard-and-custom-records.md)\n• Twenty connector configuration (../reference/configuration.md)\n• Approvals and policy (../../../concepts/approvals-and-policy.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "548efdd6415db843e249bfa54462de1a3746c62a9c0e0ff9899ea41fa6158a0a"
  }
}