{
  "schemaVersion": "1.0",
  "title": "Cal.diy capabilities",
  "description": "Use this index to choose the Cal.diy operation family that owns your task and to interpret its AIP contract before invocation. The reviewed catalogue contains 81 unique capabilities. Each id begins with cap:caldiy: and maps to one fixed pro",
  "canonical": "https://getaip.org/docs/connectors/cal-diy/capabilities",
  "route": "/docs/connectors/cal-diy/capabilities",
  "source": "docs/connectors/cal-diy/capabilities/README.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/cal-diy/capabilities.md",
    "txt": "/docs/download/connectors/cal-diy/capabilities.txt",
    "json": "/docs/download/connectors/cal-diy/capabilities.json",
    "pdf": "/docs/download/connectors/cal-diy/capabilities.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Cal.diy capabilities\ndescription: Choose a capability family and interpret its risk, approval, retry, and side-effect contract\nkind: index\naudience: application-developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: cal-diy\n---\n\n# Cal.diy capabilities\n\nUse this index to choose the Cal.diy operation family that owns your task and\nto interpret its AIP contract before invocation. The reviewed catalogue contains\n81 unique capabilities. Each id begins with `cap:cal_diy:` and maps to one fixed\nprovider method, path template, and API version.\n\nThe source-derived [capability snapshot](../assets/capabilities.json) contains\nstable catalogue markers for tooling and review. The family pages own inputs,\nresults, side effects, and task guidance; the JSON snapshot does not replace\nthe AIP schemas or the code that constructs each capability.\n\n## Catalogue identity\n\n| Property | Value |\n|---|---|\n| Reviewed AIP source | `97be86e9efedf07ecf1783b03800f683f107fb04` |\n| Pinned Cal.diy source | `f00434927386c9ecdcbd7e6c5f82d22044a245bc` |\n| Connector profile | `aip.connector.cal_diy.v1` |\n| Capability prefix | `cap:cal_diy:` |\n| Operations | 81 |\n| Reads | 36 |\n| Mutations | 45 |\n| Approval required | 47 |\n\nA different connector artifact or provider revision requires a new snapshot\nand review. Do not infer support from a matching capability id alone.\n\n## Choose a family\n\n| Family | Page | Total | Reads | Mutations | Low | Medium | High | Approval |\n|---|---|---:|---:|---:|---:|---:|---:|---:|\n| Profile | `profile.md` | 2 | 1 | 1 | 1 | 1 | 0 | 1 |\n| Event types and private links | `event-types-and-private-links.md` | 15 | 5 | 10 | 5 | 6 | 4 | 10 |\n| Slots and reservations | `slots-and-reservations.md` | 5 | 2 | 3 | 2 | 2 | 1 | 3 |\n| Bookings | `bookings.md` | 22 | 10 | 12 | 8 | 4 | 10 | 14 |\n| Calendars and free/busy | `calendars-and-free-busy.md` | 21 | 11 | 10 | 11 | 6 | 4 | 10 |\n| Conferencing | `conferencing.md` | 5 | 2 | 3 | 2 | 2 | 1 | 3 |\n| Schedules | `schedules.md` | 6 | 3 | 3 | 3 | 2 | 1 | 3 |\n| User webhooks | `webhooks.md` | 5 | 2 | 3 | 2 | 2 | 1 | 3 |\n| **Total** |  | **81** | **36** | **45** | **34** | **25** | **22** | **47** |\n\nBooking attendee and artifact operations are documented separately in\n`booking-attendees-and-artifacts.md`, but they remain part of the 22-operation\nbooking family. The family table counts each operation once.\n\n## Read a capability id\n\nThe suffix after `cap:cal_diy:` names the resource and operation:\n\n```text\ncap:cal_diy:booking.create\n│             │       └─ operation\n│             └──────── resource family\n└────────────────────── connector namespace\n```\n\nNested resources add stable segments:\n\n```text\ncap:cal_diy:event_type.private_link.create\ncap:cal_diy:calendar.connection.event.update\ncap:cal_diy:booking.conferencing_session.list\n```\n\nDo not construct an undocumented suffix from a provider route. Discovery and\nthe source-derived snapshot are the operation inventory.\n\nEach advertised capability has bindings for `aip.native.http.v1` and\n`aip.connector.cal_diy.v1`. Binding metadata identifies the Cal.diy system,\nconnector id, operation suffix, provider method, fixed path template, and\nselected API version.\n\n## HTTP method and operation class\n\n| Provider method | Count | AIP class |\n|---|---:|---|\n| `GET` | 36 | Read |\n| `POST` | 22 | Mutation |\n| `PATCH` | 10 | Mutation |\n| `PUT` | 1 | Mutation |\n| `DELETE` | 12 | Mutation |\n\nThe connector classifies a capability as a read only when its provider method\nis `GET`. Every other method receives the mutation contract, even when a\nprovider operation sounds reversible or administrative.\n\n## Risk legend\n\nRisk is a declared input to policy, not authorization by itself.\n\n| Risk | Count | Cal.diy classification rule | Required decision |\n|---|---:|---|---|\n| Low | 34 | Read other than recording or transcript access | Authenticate, authorize, and apply data policy |\n| Medium | 25 | Mutation that is neither destructive nor one of the named high-impact booking transitions | Require approval and an idempotency key |\n| High | 22 | Destructive operation, recording or transcript read, booking reschedule, confirmation, absence update, or reassignment | Apply the stricter tenant policy and inspect exact impact |\n\n`booking.create` is medium risk in the reviewed source but still requires\napproval, external-account idempotency, and a plan before commit. Never use a\nrisk label to skip the other contract fields.\n\n## Approval legend\n\nApproval is required for:\n\n- all 45 mutations; and\n- `cap:cal_diy:booking.recording.list` and\n  `cap:cal_diy:booking.transcript.list` because they may expose restricted\n  meeting data.\n\nThe advertised approval policy uses the tenant-policy selector, a 900,000 ms\nvalidity window, and three evidence requirements:\n\n- reason;\n- input snapshot;\n- policy decision.\n\nThe capability does not grant delegated approval authority. An approval must\nbind the actual authenticated actor, tenant, capability, and reviewed input.\nExpiry or input change requires a new decision.\n\n## Idempotency and retry legend\n\n| Contract | Reads | Mutations |\n|---|---|---|\n| Idempotency key | Optional | Required |\n| Key scope | Action | External account |\n| Collision behavior | Revalidate input hash | Revalidate input hash |\n| Connector retry support | Yes | No |\n| Retry safety | Safe | Unsafe |\n| Published key TTL | None | None |\n\nFor a mutation, reuse the same key only with the same capability, account, and\ncanonical input. A different input is an idempotency collision.\n\nThe connector records a durable claim before provider dispatch. A completed\nmatching claim can return its stored result. An in-flight claim remains in\nprogress. A dispatch that may have crossed the provider boundary without a\ntrusted outcome becomes uncertain and must not be retried automatically.\n\nThe absence of a contract TTL does not authorize uncontrolled key reuse or\ndeletion of durable state. Retention and reconciliation remain deployment\npolicy.\n\n## Execution legend\n\nAll 81 capabilities advertise:\n\n| Field | Value |\n|---|---|\n| Synchronous execution | Supported |\n| Connector-managed async execution | Not supported |\n| Streaming | Not supported |\n| Cancellation | Not supported |\n| Expected completion | Synchronous |\n| Provider timeout | 30,000 ms |\n| Expected latency hint | 2,000 ms for reads; 5,000 ms for mutations |\n| Maximum queue-delay hint | 5,000 ms |\n| Availability target | Not declared |\n\nThese are capability-contract hints and bounds, not a deployment SLO or\nqualification result.\n\n## Transaction legend\n\nEvery mutation declares four modes:\n\n```text\ndry_run | plan | commit | reconcile\n```\n\nOnly three operations require a validated plan before commit:\n\n- `cap:cal_diy:booking.create`;\n- `cap:cal_diy:booking.reschedule`;\n- `cap:cal_diy:booking.cancel`.\n\nTheir dry run has downstream-validation fidelity. Other mutations declare\npolicy-and-schema fidelity; a successful dry run does not promise that Cal.diy\naccepted a provider-side preview.\n\nReconcile interprets durable dispatch evidence. It does not issue a speculative\nrepeat. An unresolved provider outcome requires operator evidence.\n\n## Side-effect legend\n\nEvery capability declares external network access plus `read` or `write`.\nAdditional markers are additive:\n\n| Marker | Operations |\n|---|---|\n| `delete` | 15 destructive operations |\n| `send_message` | Booking create, reschedule, cancel, confirm, decline, attendee add or remove, and guest add |\n| `identity` | Profile update |\n\nThe `send_message` marker means the provider operation may update invitations,\nconnected calendars, or customer-visible notifications. It does not guarantee\nthat a particular notification was delivered.\n\n## Compensation legend\n\nEleven create or connect operations name a best-effort compensating capability:\n\n| Original | Compensation |\n|---|---|\n| `event_type.create` | `event_type.delete` |\n| `event_type.private_link.create` | `event_type.private_link.delete` |\n| `event_type.webhook.create` | `event_type.webhook.delete` |\n| `slot.reservation.create` | `slot.reservation.delete` |\n| `booking.create` | `booking.cancel` |\n| `calendar.connection.event.create` | `calendar.connection.event.delete` |\n| `calendar.event.create` | `calendar.event.delete` |\n| `calendar.selected.add` | `calendar.selected.delete` |\n| `conferencing.connect` | `conferencing.disconnect` |\n| `schedule.create` | `schedule.delete` |\n| `webhook.create` | `webhook.delete` |\n\nThe declared compensation window is 86,400,000 ms and compensation itself\nrequires approval. It is a new provider operation, not an atomic rollback.\nReads require no compensation. Mutations without a named inverse declare that\nrollback is not supported.\n\n## Data legend\n\nThe connector declares one of three data sensitivity levels:\n\n- `slot.list` is public;\n- profile, private-link, webhook, booking, calendar, recording, and transcript\n  operations are restricted;\n- remaining event-type, slot-reservation, conferencing, and schedule\n  operations are confidential.\n\nRestricted operations and every event-type operation are marked as containing\nPII and requiring redaction. This contract is a minimum handling signal. Input\nor provider output may require stricter classification under deployment policy.\n\nThe connector recursively redacts known secret fields from provider results,\nbut data classification and authorization must occur before output is returned\nto another system or model.\n\n## Credential legend\n\nEvery operation names the logical issuer `cal_diy_deployment` and an exact\nscope of the form:\n\n```text\ncal_diy:<operation-suffix>\n```\n\nFor example, `cap:cal_diy:booking.create` names\n`cal_diy:booking.create`.\n\nThe standalone host's manifest does not require a per-action credential handle\nbecause that binary uses one startup-loaded provider credential. This does not\nmake the provider credential optional. The separate connector-library tenant\nrouting composition marks handles as required and validates issuer, tenant,\nexpiry, and operation scope.\n\nOAuth refresh is not allowed through the capability contract.\n\n## Use the machine snapshot\n\n[`assets/capabilities.json`](../assets/capabilities.json) is a source-derived\nreview artifact with:\n\n- exact source and upstream revisions;\n- family, method, risk, approval, destructive, plan, and compensation counts;\n- one ordered record per operation;\n- stable capability id, provider method and API version;\n- risk, approval reason class, side effects, idempotency, execution, data,\n  credential scope, and compensation markers.\n\nIt intentionally omits the full input and output schemas and provider path\ntemplates owned by their generated or family references. Treat the source\nrevision as part of the asset identity. A catalogue change without a matching\nsnapshot update is documentation drift and must fail review.\n\n## Choose the next page\n\n- Use `profile.md` for authenticated profile reads and updates.\n- Use `event-types-and-private-links.md` for event definitions, access links,\n  and event-scoped webhooks.\n- Use `slots-and-reservations.md` before creating a booking.\n- Use `bookings.md` for booking state and lifecycle transitions.\n- Use `booking-attendees-and-artifacts.md` for people, references, recordings,\n  transcripts, and conferencing-session results.\n- Use `calendars-and-free-busy.md` for connected calendars, events, and\n  conflict selection.\n- Use `conferencing.md`, `schedules.md`, or `webhooks.md` for those provider\n  resources.\n\n## Related documentation\n\n- [Cal.diy connector overview](../README.md)\n- [Cal.diy configuration](../reference/configuration.md)\n- [Capabilities and contracts](../../../concepts/capabilities.md)\n- [Approvals and policy](../../../concepts/approvals-and-policy.md)\n- [Transactions and compensation](../../../concepts/transactions-and-compensation.md)\n",
    "text": "Cal.diy capabilities\n\nUse this index to choose the Cal.diy operation family that owns your task and\nto interpret its AIP contract before invocation. The reviewed catalogue contains\n81 unique capabilities. Each id begins with cap:caldiy: and maps to one fixed\nprovider method, path template, and API version.\n\nThe source-derived capability snapshot (../assets/capabilities.json) contains\nstable catalogue markers for tooling and review. The family pages own inputs,\nresults, side effects, and task guidance; the JSON snapshot does not replace\nthe AIP schemas or the code that constructs each capability.\n\nCatalogue identity\n\n| Property | Value |\n\n| Reviewed AIP source | 97be86e9efedf07ecf1783b03800f683f107fb04 |\n| Pinned Cal.diy source | f00434927386c9ecdcbd7e6c5f82d22044a245bc |\n| Connector profile | aip.connector.caldiy.v1 |\n| Capability prefix | cap:caldiy: |\n| Operations | 81 |\n| Reads | 36 |\n| Mutations | 45 |\n| Approval required | 47 |\n\nA different connector artifact or provider revision requires a new snapshot\nand review. Do not infer support from a matching capability id alone.\n\nChoose a family\n\n| Family | Page | Total | Reads | Mutations | Low | Medium | High | Approval |\n\n| Profile | profile.md | 2 | 1 | 1 | 1 | 1 | 0 | 1 |\n| Event types and private links | event-types-and-private-links.md | 15 | 5 | 10 | 5 | 6 | 4 | 10 |\n| Slots and reservations | slots-and-reservations.md | 5 | 2 | 3 | 2 | 2 | 1 | 3 |\n| Bookings | bookings.md | 22 | 10 | 12 | 8 | 4 | 10 | 14 |\n| Calendars and free/busy | calendars-and-free-busy.md | 21 | 11 | 10 | 11 | 6 | 4 | 10 |\n| Conferencing | conferencing.md | 5 | 2 | 3 | 2 | 2 | 1 | 3 |\n| Schedules | schedules.md | 6 | 3 | 3 | 3 | 2 | 1 | 3 |\n| User webhooks | webhooks.md | 5 | 2 | 3 | 2 | 2 | 1 | 3 |\n| Total |  | 81 | 36 | 45 | 34 | 25 | 22 | 47 |\n\nBooking attendee and artifact operations are documented separately in\nbooking-attendees-and-artifacts.md, but they remain part of the 22-operation\nbooking family. The family table counts each operation once.\n\nRead a capability id\n\nThe suffix after cap:caldiy: names the resource and operation:\n\ncap:caldiy:booking.create\n│             │       └─ operation\n│             └──────── resource family\n└────────────────────── connector namespace\n\nNested resources add stable segments:\n\ncap:caldiy:eventtype.privatelink.create\ncap:caldiy:calendar.connection.event.update\ncap:caldiy:booking.conferencingsession.list\n\nDo not construct an undocumented suffix from a provider route. Discovery and\nthe source-derived snapshot are the operation inventory.\n\nEach advertised capability has bindings for aip.native.http.v1 and\naip.connector.caldiy.v1. Binding metadata identifies the Cal.diy system,\nconnector id, operation suffix, provider method, fixed path template, and\nselected API version.\n\nHTTP method and operation class\n\n| Provider method | Count | AIP class |\n\n| GET | 36 | Read |\n| POST | 22 | Mutation |\n| PATCH | 10 | Mutation |\n| PUT | 1 | Mutation |\n| DELETE | 12 | Mutation |\n\nThe connector classifies a capability as a read only when its provider method\nis GET. Every other method receives the mutation contract, even when a\nprovider operation sounds reversible or administrative.\n\nRisk legend\n\nRisk is a declared input to policy, not authorization by itself.\n\n| Risk | Count | Cal.diy classification rule | Required decision |\n\n| Low | 34 | Read other than recording or transcript access | Authenticate, authorize, and apply data policy |\n| Medium | 25 | Mutation that is neither destructive nor one of the named high-impact booking transitions | Require approval and an idempotency key |\n| High | 22 | Destructive operation, recording or transcript read, booking reschedule, confirmation, absence update, or reassignment | Apply the stricter tenant policy and inspect exact impact |\n\nbooking.create is medium risk in the reviewed source but still requires\napproval, external-account idempotency, and a plan before commit. Never use a\nrisk label to skip the other contract fields.\n\nApproval legend\n\nApproval is required for:\n• all 45 mutations; and\n• cap:caldiy:booking.recording.list and\n  cap:caldiy:booking.transcript.list because they may expose restricted\n  meeting data.\n\nThe advertised approval policy uses the tenant-policy selector, a 900,000 ms\nvalidity window, and three evidence requirements:\n• reason;\n• input snapshot;\n• policy decision.\n\nThe capability does not grant delegated approval authority. An approval must\nbind the actual authenticated actor, tenant, capability, and reviewed input.\nExpiry or input change requires a new decision.\n\nIdempotency and retry legend\n\n| Contract | Reads | Mutations |\n\n| Idempotency key | Optional | Required |\n| Key scope | Action | External account |\n| Collision behavior | Revalidate input hash | Revalidate input hash |\n| Connector retry support | Yes | No |\n| Retry safety | Safe | Unsafe |\n| Published key TTL | None | None |\n\nFor a mutation, reuse the same key only with the same capability, account, and\ncanonical input. A different input is an idempotency collision.\n\nThe connector records a durable claim before provider dispatch. A completed\nmatching claim can return its stored result. An in-flight claim remains in\nprogress. A dispatch that may have crossed the provider boundary without a\ntrusted outcome becomes uncertain and must not be retried automatically.\n\nThe absence of a contract TTL does not authorize uncontrolled key reuse or\ndeletion of durable state. Retention and reconciliation remain deployment\npolicy.\n\nExecution legend\n\nAll 81 capabilities advertise:\n\n| Field | Value |\n\n| Synchronous execution | Supported |\n| Connector-managed async execution | Not supported |\n| Streaming | Not supported |\n| Cancellation | Not supported |\n| Expected completion | Synchronous |\n| Provider timeout | 30,000 ms |\n| Expected latency hint | 2,000 ms for reads; 5,000 ms for mutations |\n| Maximum queue-delay hint | 5,000 ms |\n| Availability target | Not declared |\n\nThese are capability-contract hints and bounds, not a deployment SLO or\nqualification result.\n\nTransaction legend\n\nEvery mutation declares four modes:\n\ndryrun | plan | commit | reconcile\n\nOnly three operations require a validated plan before commit:\n• cap:caldiy:booking.create;\n• cap:caldiy:booking.reschedule;\n• cap:caldiy:booking.cancel.\n\nTheir dry run has downstream-validation fidelity. Other mutations declare\npolicy-and-schema fidelity; a successful dry run does not promise that Cal.diy\naccepted a provider-side preview.\n\nReconcile interprets durable dispatch evidence. It does not issue a speculative\nrepeat. An unresolved provider outcome requires operator evidence.\n\nSide-effect legend\n\nEvery capability declares external network access plus read or write.\nAdditional markers are additive:\n\n| Marker | Operations |\n\n| delete | 15 destructive operations |\n| sendmessage | Booking create, reschedule, cancel, confirm, decline, attendee add or remove, and guest add |\n| identity | Profile update |\n\nThe sendmessage marker means the provider operation may update invitations,\nconnected calendars, or customer-visible notifications. It does not guarantee\nthat a particular notification was delivered.\n\nCompensation legend\n\nEleven create or connect operations name a best-effort compensating capability:\n\n| Original | Compensation |\n\n| eventtype.create | eventtype.delete |\n| eventtype.privatelink.create | eventtype.privatelink.delete |\n| eventtype.webhook.create | eventtype.webhook.delete |\n| slot.reservation.create | slot.reservation.delete |\n| booking.create | booking.cancel |\n| calendar.connection.event.create | calendar.connection.event.delete |\n| calendar.event.create | calendar.event.delete |\n| calendar.selected.add | calendar.selected.delete |\n| conferencing.connect | conferencing.disconnect |\n| schedule.create | schedule.delete |\n| webhook.create | webhook.delete |\n\nThe declared compensation window is 86,400,000 ms and compensation itself\nrequires approval. It is a new provider operation, not an atomic rollback.\nReads require no compensation. Mutations without a named inverse declare that\nrollback is not supported.\n\nData legend\n\nThe connector declares one of three data sensitivity levels:\n• slot.list is public;\n• profile, private-link, webhook, booking, calendar, recording, and transcript\n  operations are restricted;\n• remaining event-type, slot-reservation, conferencing, and schedule\n  operations are confidential.\n\nRestricted operations and every event-type operation are marked as containing\nPII and requiring redaction. This contract is a minimum handling signal. Input\nor provider output may require stricter classification under deployment policy.\n\nThe connector recursively redacts known secret fields from provider results,\nbut data classification and authorization must occur before output is returned\nto another system or model.\n\nCredential legend\n\nEvery operation names the logical issuer caldiydeployment and an exact\nscope of the form:\n\ncaldiy:\n\nFor example, cap:caldiy:booking.create names\ncaldiy:booking.create.\n\nThe standalone host's manifest does not require a per-action credential handle\nbecause that binary uses one startup-loaded provider credential. This does not\nmake the provider credential optional. The separate connector-library tenant\nrouting composition marks handles as required and validates issuer, tenant,\nexpiry, and operation scope.\n\nOAuth refresh is not allowed through the capability contract.\n\nUse the machine snapshot\n\nassets/capabilities.json (../assets/capabilities.json) is a source-derived\nreview artifact with:\n• exact source and upstream revisions;\n• family, method, risk, approval, destructive, plan, and compensation counts;\n• one ordered record per operation;\n• stable capability id, provider method and API version;\n• risk, approval reason class, side effects, idempotency, execution, data,\n  credential scope, and compensation markers.\n\nIt intentionally omits the full input and output schemas and provider path\ntemplates owned by their generated or family references. Treat the source\nrevision as part of the asset identity. A catalogue change without a matching\nsnapshot update is documentation drift and must fail review.\n\nChoose the next page\n• Use profile.md for authenticated profile reads and updates.\n• Use event-types-and-private-links.md for event definitions, access links,\n  and event-scoped webhooks.\n• Use slots-and-reservations.md before creating a booking.\n• Use bookings.md for booking state and lifecycle transitions.\n• Use booking-attendees-and-artifacts.md for people, references, recordings,\n  transcripts, and conferencing-session results.\n• Use calendars-and-free-busy.md for connected calendars, events, and\n  conflict selection.\n• Use conferencing.md, schedules.md, or webhooks.md for those provider\n  resources.\n\nRelated documentation\n• Cal.diy connector overview (../README.md)\n• Cal.diy configuration (../reference/configuration.md)\n• Capabilities and contracts (../../../concepts/capabilities.md)\n• Approvals and policy (../../../concepts/approvals-and-policy.md)\n• Transactions and compensation (../../../concepts/transactions-and-compensation.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "e1eef89308d4e05cde930da4857a28e77c82b5f8a62e3b52ac8469a07f62e439"
  }
}