{
  "schemaVersion": "1.0",
  "title": "Cal.diy booking attendees and artifacts",
  "description": "Use these capabilities to manage the people attached to a booking or to read its generated calendar links, provider references, recording and transcript metadata, and conferencing sessions. This page owns the remaining 10 operations in the ",
  "canonical": "https://getaip.org/docs/connectors/cal-diy/capabilities/booking-attendees-and-artifacts",
  "route": "/docs/connectors/cal-diy/capabilities/booking-attendees-and-artifacts",
  "source": "docs/connectors/cal-diy/capabilities/booking-attendees-and-artifacts.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/cal-diy/capabilities/booking-attendees-and-artifacts.md",
    "txt": "/docs/download/connectors/cal-diy/capabilities/booking-attendees-and-artifacts.txt",
    "json": "/docs/download/connectors/cal-diy/capabilities/booking-attendees-and-artifacts.json",
    "pdf": "/docs/download/connectors/cal-diy/capabilities/booking-attendees-and-artifacts.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Cal.diy booking attendees and artifacts\ndescription: Manage attendees and guests or read restricted booking links, media metadata, and sessions\nkind: capability-reference\naudience: application-developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: cal-diy\ncapabilityIds:\n  - cap:cal_diy:booking.attendee.list\n  - cap:cal_diy:booking.attendee.get\n  - cap:cal_diy:booking.attendee.add\n  - cap:cal_diy:booking.attendee.delete\n  - cap:cal_diy:booking.guest.add\n  - cap:cal_diy:booking.calendar_links.get\n  - cap:cal_diy:booking.reference.list\n  - cap:cal_diy:booking.recording.list\n  - cap:cal_diy:booking.transcript.list\n  - cap:cal_diy:booking.conferencing_session.list\n---\n\n# Cal.diy booking attendees and artifacts\n\nUse these capabilities to manage the people attached to a booking or to read\nits generated calendar links, provider references, recording and transcript\nmetadata, and conferencing sessions. This page owns the remaining 10\noperations in the 22-operation booking family.\n\nAll operations use provider API version `2024-08-13`. Every input and result in\nthis group is restricted, contains PII, and requires redaction.\n\n## Choose an operation\n\n### Attendees and guests\n\n| Capability | Provider request | Risk | Approval |\n|---|---|---|---|\n| `cap:cal_diy:booking.attendee.list` | `GET /v2/bookings/{booking_uid}/attendees` | Low | No |\n| `cap:cal_diy:booking.attendee.get` | `GET /v2/bookings/{booking_uid}/attendees/{attendee_id}` | Low | No |\n| `cap:cal_diy:booking.attendee.add` | `POST /v2/bookings/{booking_uid}/attendees` | Medium | Required |\n| `cap:cal_diy:booking.attendee.delete` | `DELETE /v2/bookings/{booking_uid}/attendees/{attendee_id}` | High | Required |\n| `cap:cal_diy:booking.guest.add` | `POST /v2/bookings/{booking_uid}/guests` | Medium | Required |\n\n### Links, references, and meeting artifacts\n\n| Capability | Provider request | Risk | Approval |\n|---|---|---|---|\n| `cap:cal_diy:booking.calendar_links.get` | `GET /v2/bookings/{booking_uid}/calendar-links` | Low | No |\n| `cap:cal_diy:booking.reference.list` | `GET /v2/bookings/{booking_uid}/references` | Low | No |\n| `cap:cal_diy:booking.recording.list` | `GET /v2/bookings/{booking_uid}/recordings` | High | Required |\n| `cap:cal_diy:booking.transcript.list` | `GET /v2/bookings/{booking_uid}/transcripts` | High | Required |\n| `cap:cal_diy:booking.conferencing_session.list` | `GET /v2/bookings/{booking_uid}/conferencing-sessions` | Low | No |\n\nRecording and transcript operations are reads, but their restricted-media\nboundary makes them high risk and approval-required.\n\n## List or read attendees\n\nList accepts only a non-empty booking uid:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\"\n}\n```\n\nRead one attendee by adding its integer provider id:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\",\n  \"attendee_id\": 73\n}\n```\n\nAdditional fields are rejected. The connector percent-encodes\n`booking_uid` into the provider path. `attendee_id` is an integer without an\nadditional minimum in the published schema; Cal.diy can still reject an id\noutside the provider's domain.\n\nThese are low-risk, retry-safe reads. No capability-level human approval is\nrequired, but normal identity, tenant, account, and restricted-data policy\nstill applies.\n\n## Add an attendee\n\nAttendee add requires the booking uid, name, time zone, and email:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\",\n  \"name\": \"Avery Patel\",\n  \"timeZone\": \"Europe/London\",\n  \"email\": \"avery@example.com\",\n  \"language\": \"en\"\n}\n```\n\n| Field | Constraint |\n|---|---|\n| `booking_uid` | Non-empty string; required |\n| `name` | Non-empty string; required |\n| `timeZone` | Non-empty string; required |\n| `email` | Email string; required |\n| `phoneNumber` | `+` plus 7 through 15 digits |\n| `language` | The 43-value Cal.diy locale enum |\n\nThe locale enum is listed in the [profile capability reference](profile.md).\nAdditional input fields are rejected.\n\nBefore the add request, the connector reads the booking. A passing preflight\nshows that the target was visible at that moment; it does not guarantee that\nthe provider will accept the attendee.\n\nThe operation is medium risk and carries `write`, `external_network`, and\n`send_message` side effects. The connector description states that it updates\nconnected calendar events. The marker does not prove that every participant\nreceived a notification or calendar update.\n\n## Remove an attendee\n\nAttendee delete uses the same two-identifier input as attendee get:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\",\n  \"attendee_id\": 73\n}\n```\n\nThe connector reads that exact attendee before deletion. The operation is high\nrisk and destructive, and it can update connected calendar events or\nparticipant-visible state.\n\nThere is no rollback or compensating capability. Adding a person later creates\na new provider change and does not restore prior invitation, attendance, or\nnotification history.\n\n## Add guests\n\nGuest add requires the `guests` field to contain 1 through 10 guest objects:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\",\n  \"guests\": [\n    {\n      \"email\": \"jordan@example.com\",\n      \"name\": \"Jordan Lee\",\n      \"timeZone\": \"America/New_York\",\n      \"language\": \"en\"\n    }\n  ]\n}\n```\n\nEach guest requires only `email`. Optional fields are `name`, `timeZone`,\n`phoneNumber`, and `language`. The guest schema does not require non-empty\n`name` or `timeZone`; provider policy may impose stricter rules. Phone and\nlanguage use the same constraints as attendee add. Additional guest fields are\nrejected.\n\nThe array does not declare `uniqueItems`, so duplicate guest objects can pass\nschema validation. Deduplicate intended recipients before approval rather than\ndepending on provider behavior.\n\nGuest add first reads the booking. It is medium risk and carries the\n`send_message` marker because the provider may send applicable notifications.\nIt declares no compensation.\n\n## Read calendar links and references\n\nCalendar-link get accepts only:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\"\n}\n```\n\nIt reads generated booking calendar links. The connector does not publish\nfield names or expiry semantics for those provider-owned links.\n\nReference list requires the same booking uid and may add one `type` filter:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\",\n  \"type\": \"google_calendar\"\n}\n```\n\nThe exact filter enum is:\n\n```text\ngoogle_calendar | office365_calendar | daily_video | google_video\noffice365_video | zoom_video\n```\n\nThe filter is optional. These references identify provider calendar or video\nsystems associated with the booking; they are not proof that an external event\nor meeting remains reachable.\n\nBoth operations are low-risk, retry-safe reads. Treat returned links and\nexternal identifiers as restricted even when a URL itself is shareable.\n\n## Read recordings and transcripts\n\nRecording and transcript list each accept only the booking uid:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\"\n}\n```\n\nThese capabilities list restricted download metadata. They do not declare a\nmedia upload, streaming, or byte-download contract, and the connector does not\npublish the provider metadata field shape.\n\nBoth operations are high-risk reads and require approval because a response\nmay expose restricted meeting media or transcript data. Approval uses the\ntenant-policy selector, a 900,000 ms validity window, and reason, input\nsnapshot, and policy-decision evidence.\n\nApproval must bind the actor, tenant, booking, capability, and exact input. A\nretry-safe marker does not bypass approval expiry, changed authorization, or a\nnew booking uid.\n\nDespite their high risk and approval requirement, both operations retain the\nread contract:\n\n- optional action-scoped idempotency;\n- connector retry support;\n- retry safety `safe`;\n- synchronous execution only.\n\nRetry only within the current approval, deadline, and data-access policy. Do\nnot automatically follow or download a URL found in provider metadata.\n\n## Read conferencing sessions\n\nConferencing-session list accepts only the booking uid and returns\nprovider-owned session metadata:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\"\n}\n```\n\nIt is a low-risk, approval-free capability at the contract level. The result\nremains restricted and PII-bearing. Session presence does not prove that a\nmeeting is active, joinable, recorded, or qualified for a particular provider.\n\n## Shared read contract\n\nAll seven reads are synchronous, retry-safe, and eligible for connector retry.\nTheir idempotency key is optional, action-scoped, and collision-checked against\nthe input hash.\n\nFive reads are low risk and do not require capability-level approval. Recording\nand transcript list are the two high-risk exceptions described above. Risk and\napproval are independent contract fields; neither changes these operations\ninto mutations.\n\n## Shared mutation contract\n\nAttendee add, attendee delete, and guest add require:\n\n| Contract field | Value |\n|---|---|\n| Human approval | Required |\n| Approval selector | Tenant policy |\n| Approval validity window | 900,000 ms |\n| Approval evidence | Reason, input snapshot, policy decision |\n| Idempotency | Required; external-account scope |\n| Collision behavior | Revalidate input hash |\n| Connector retry | Not supported |\n| Retry safety | Unsafe |\n| Execution | Synchronous only |\n| Transaction modes | `dry_run`, `plan`, `commit`, `reconcile` |\n| Plan before commit | Not required |\n| Dry-run fidelity | Policy and schema only |\n\nAll three mutations carry `send_message`. None declares a compensating\ncapability. Attendee delete is destructive and uses the stricter destructive\napproval reason; add operations use the customer-visible-change reason.\n\nAn uncertain provider dispatch must be reconciled from the original durable\noperation. Do not issue the same people-changing action under a replacement key.\n\n## Result and redaction contract\n\nThe connector returns the validated provider JSON body as AIP output. A\nnon-empty string `status` is required. `data`, `pagination`, and additional\nprovider fields are optional; their shapes are not guaranteed by the connector\nschema.\n\nThe connector recursively replaces secret-, key-, and token-named values with\n`[REDACTED]`. This targeted redaction does not remove booking names, email\naddresses, phone numbers, URLs, transcripts, recording metadata, or other PII\nunless their field names match the secret redactor. Keep the full output under\nrestricted-data controls.\n\n## Failures and recovery\n\n| Failure | Relevant cause | Safe response |\n|---|---|---|\n| `connector.cal_diy.invalid_action` | Missing id, invalid attendee or guest, unsupported reference type, or unknown field | Correct the exact input before another call |\n| `connector.cal_diy.policy` | Mutation omitted its required idempotency key | Preserve the approved input and add the missing key |\n| `connector.cal_diy.idempotency_collision` | One mutation key owns different input | Stop and inspect the original action |\n| `connector.cal_diy.in_flight` | A matching people mutation is executing | Read durable state and wait |\n| `connector.cal_diy.outcome_unknown` | Prior provider dispatch cannot be proved | Reconcile; never create a speculative replacement key |\n| `connector.cal_diy.authentication` | Provider returned `401` or `403` | Verify account binding, credential revision, booking ownership, and media authorization |\n| `connector.cal_diy.state_conflict` | Provider returned `409` or `412` | Refresh booking or attendee state and review the requested change |\n| `connector.cal_diy.rate_limited` | Provider returned `429` | Retry reads within current approval and policy; reconcile mutations |\n| `connector.cal_diy.remote_temporary` | Provider returned a server error | Retry reads within policy; reconcile mutations |\n| `connector.cal_diy.transport` | Provider exchange failed | Retry reads only; treat dispatched mutations as uncertain |\n| `connector.cal_diy.invalid_provider_output` | Successful response lacked a valid `status` | Preserve evidence and reconcile a mutation |\n\nPermanent provider rejection, invalid credentials, oversized responses, and\ndurable settlement failures use the common Cal.diy error family. Gateway and\nlifecycle errors are described in the [global error reference](../../../reference/errors.md).\n\n## Verify attendee or artifact handling\n\nFor attendee changes, verify the approval and idempotency key, wait for a\ncompleted durable result, then list attendees or read the exact attendee. For\nguest add, read the booking and compare only the intended guest change.\n\nFor artifact reads, verify the exact capability, booking uid, actor, tenant,\nexternal account, approval when required, response status, and data-handling\ndecision. Do not expose metadata merely because the operation completed.\n\nRetain the provider request id when present. Reconcile uncertain mutations and\nnever use a follow-up read as authorization to repeat a people-changing action.\n\nThese checks validate application handling. They do not prove notification\ndelivery, media accessibility, live-provider qualification, or production\nreadiness.\n\n## Related documentation\n\n- [Cal.diy capability index](README.md)\n- [Core booking capabilities](bookings.md)\n- [Authentication and tenant routing](../getting-started/authentication-and-tenant-routing.md)\n- [Transactions and compensation](../../../concepts/transactions-and-compensation.md)\n- [Error reference](../../../reference/errors.md)\n",
    "text": "Cal.diy booking attendees and artifacts\n\nUse these capabilities to manage the people attached to a booking or to read\nits generated calendar links, provider references, recording and transcript\nmetadata, and conferencing sessions. This page owns the remaining 10\noperations in the 22-operation booking family.\n\nAll operations use provider API version 2024-08-13. Every input and result in\nthis group is restricted, contains PII, and requires redaction.\n\nChoose an operation\n\nAttendees and guests\n\n| Capability | Provider request | Risk | Approval |\n\n| cap:caldiy:booking.attendee.list | GET /v2/bookings/{bookinguid}/attendees | Low | No |\n| cap:caldiy:booking.attendee.get | GET /v2/bookings/{bookinguid}/attendees/{attendeeid} | Low | No |\n| cap:caldiy:booking.attendee.add | POST /v2/bookings/{bookinguid}/attendees | Medium | Required |\n| cap:caldiy:booking.attendee.delete | DELETE /v2/bookings/{bookinguid}/attendees/{attendeeid} | High | Required |\n| cap:caldiy:booking.guest.add | POST /v2/bookings/{bookinguid}/guests | Medium | Required |\n\nLinks, references, and meeting artifacts\n\n| Capability | Provider request | Risk | Approval |\n\n| cap:caldiy:booking.calendarlinks.get | GET /v2/bookings/{bookinguid}/calendar-links | Low | No |\n| cap:caldiy:booking.reference.list | GET /v2/bookings/{bookinguid}/references | Low | No |\n| cap:caldiy:booking.recording.list | GET /v2/bookings/{bookinguid}/recordings | High | Required |\n| cap:caldiy:booking.transcript.list | GET /v2/bookings/{bookinguid}/transcripts | High | Required |\n| cap:caldiy:booking.conferencingsession.list | GET /v2/bookings/{bookinguid}/conferencing-sessions | Low | No |\n\nRecording and transcript operations are reads, but their restricted-media\nboundary makes them high risk and approval-required.\n\nList or read attendees\n\nList accepts only a non-empty booking uid:\n\n{\n  \"bookinguid\": \"booking-provider-uid\"\n}\n\nRead one attendee by adding its integer provider id:\n\n{\n  \"bookinguid\": \"booking-provider-uid\",\n  \"attendeeid\": 73\n}\n\nAdditional fields are rejected. The connector percent-encodes\nbookinguid into the provider path. attendeeid is an integer without an\nadditional minimum in the published schema; Cal.diy can still reject an id\noutside the provider's domain.\n\nThese are low-risk, retry-safe reads. No capability-level human approval is\nrequired, but normal identity, tenant, account, and restricted-data policy\nstill applies.\n\nAdd an attendee\n\nAttendee add requires the booking uid, name, time zone, and email:\n\n{\n  \"bookinguid\": \"booking-provider-uid\",\n  \"name\": \"Avery Patel\",\n  \"timeZone\": \"Europe/London\",\n  \"email\": \"avery@example.com\",\n  \"language\": \"en\"\n}\n\n| Field | Constraint |\n\n| bookinguid | Non-empty string; required |\n| name | Non-empty string; required |\n| timeZone | Non-empty string; required |\n| email | Email string; required |\n| phoneNumber | + plus 7 through 15 digits |\n| language | The 43-value Cal.diy locale enum |\n\nThe locale enum is listed in the profile capability reference (profile.md).\nAdditional input fields are rejected.\n\nBefore the add request, the connector reads the booking. A passing preflight\nshows that the target was visible at that moment; it does not guarantee that\nthe provider will accept the attendee.\n\nThe operation is medium risk and carries write, externalnetwork, and\nsendmessage side effects. The connector description states that it updates\nconnected calendar events. The marker does not prove that every participant\nreceived a notification or calendar update.\n\nRemove an attendee\n\nAttendee delete uses the same two-identifier input as attendee get:\n\n{\n  \"bookinguid\": \"booking-provider-uid\",\n  \"attendeeid\": 73\n}\n\nThe connector reads that exact attendee before deletion. The operation is high\nrisk and destructive, and it can update connected calendar events or\nparticipant-visible state.\n\nThere is no rollback or compensating capability. Adding a person later creates\na new provider change and does not restore prior invitation, attendance, or\nnotification history.\n\nAdd guests\n\nGuest add requires the guests field to contain 1 through 10 guest objects:\n\n{\n  \"bookinguid\": \"booking-provider-uid\",\n  \"guests\": [\n    {\n      \"email\": \"jordan@example.com\",\n      \"name\": \"Jordan Lee\",\n      \"timeZone\": \"America/NewYork\",\n      \"language\": \"en\"\n    }\n  ]\n}\n\nEach guest requires only email. Optional fields are name, timeZone,\nphoneNumber, and language. The guest schema does not require non-empty\nname or timeZone; provider policy may impose stricter rules. Phone and\nlanguage use the same constraints as attendee add. Additional guest fields are\nrejected.\n\nThe array does not declare uniqueItems, so duplicate guest objects can pass\nschema validation. Deduplicate intended recipients before approval rather than\ndepending on provider behavior.\n\nGuest add first reads the booking. It is medium risk and carries the\nsendmessage marker because the provider may send applicable notifications.\nIt declares no compensation.\n\nRead calendar links and references\n\nCalendar-link get accepts only:\n\n{\n  \"bookinguid\": \"booking-provider-uid\"\n}\n\nIt reads generated booking calendar links. The connector does not publish\nfield names or expiry semantics for those provider-owned links.\n\nReference list requires the same booking uid and may add one type filter:\n\n{\n  \"bookinguid\": \"booking-provider-uid\",\n  \"type\": \"googlecalendar\"\n}\n\nThe exact filter enum is:\n\ngooglecalendar | office365calendar | dailyvideo | googlevideo\noffice365video | zoomvideo\n\nThe filter is optional. These references identify provider calendar or video\nsystems associated with the booking; they are not proof that an external event\nor meeting remains reachable.\n\nBoth operations are low-risk, retry-safe reads. Treat returned links and\nexternal identifiers as restricted even when a URL itself is shareable.\n\nRead recordings and transcripts\n\nRecording and transcript list each accept only the booking uid:\n\n{\n  \"bookinguid\": \"booking-provider-uid\"\n}\n\nThese capabilities list restricted download metadata. They do not declare a\nmedia upload, streaming, or byte-download contract, and the connector does not\npublish the provider metadata field shape.\n\nBoth operations are high-risk reads and require approval because a response\nmay expose restricted meeting media or transcript data. Approval uses the\ntenant-policy selector, a 900,000 ms validity window, and reason, input\nsnapshot, and policy-decision evidence.\n\nApproval must bind the actor, tenant, booking, capability, and exact input. A\nretry-safe marker does not bypass approval expiry, changed authorization, or a\nnew booking uid.\n\nDespite their high risk and approval requirement, both operations retain the\nread contract:\n• optional action-scoped idempotency;\n• connector retry support;\n• retry safety safe;\n• synchronous execution only.\n\nRetry only within the current approval, deadline, and data-access policy. Do\nnot automatically follow or download a URL found in provider metadata.\n\nRead conferencing sessions\n\nConferencing-session list accepts only the booking uid and returns\nprovider-owned session metadata:\n\n{\n  \"bookinguid\": \"booking-provider-uid\"\n}\n\nIt is a low-risk, approval-free capability at the contract level. The result\nremains restricted and PII-bearing. Session presence does not prove that a\nmeeting is active, joinable, recorded, or qualified for a particular provider.\n\nShared read contract\n\nAll seven reads are synchronous, retry-safe, and eligible for connector retry.\nTheir idempotency key is optional, action-scoped, and collision-checked against\nthe input hash.\n\nFive reads are low risk and do not require capability-level approval. Recording\nand transcript list are the two high-risk exceptions described above. Risk and\napproval are independent contract fields; neither changes these operations\ninto mutations.\n\nShared mutation contract\n\nAttendee add, attendee delete, and guest add require:\n\n| Contract field | Value |\n\n| Human approval | Required |\n| Approval selector | Tenant policy |\n| Approval validity window | 900,000 ms |\n| Approval evidence | Reason, input snapshot, policy decision |\n| Idempotency | Required; external-account scope |\n| Collision behavior | Revalidate input hash |\n| Connector retry | Not supported |\n| Retry safety | Unsafe |\n| Execution | Synchronous only |\n| Transaction modes | dryrun, plan, commit, reconcile |\n| Plan before commit | Not required |\n| Dry-run fidelity | Policy and schema only |\n\nAll three mutations carry sendmessage. None declares a compensating\ncapability. Attendee delete is destructive and uses the stricter destructive\napproval reason; add operations use the customer-visible-change reason.\n\nAn uncertain provider dispatch must be reconciled from the original durable\noperation. Do not issue the same people-changing action under a replacement key.\n\nResult and redaction contract\n\nThe connector returns the validated provider JSON body as AIP output. A\nnon-empty string status is required. data, pagination, and additional\nprovider fields are optional; their shapes are not guaranteed by the connector\nschema.\n\nThe connector recursively replaces secret-, key-, and token-named values with\n[REDACTED]. This targeted redaction does not remove booking names, email\naddresses, phone numbers, URLs, transcripts, recording metadata, or other PII\nunless their field names match the secret redactor. Keep the full output under\nrestricted-data controls.\n\nFailures and recovery\n\n| Failure | Relevant cause | Safe response |\n\n| connector.caldiy.invalidaction | Missing id, invalid attendee or guest, unsupported reference type, or unknown field | Correct the exact input before another call |\n| connector.caldiy.policy | Mutation omitted its required idempotency key | Preserve the approved input and add the missing key |\n| connector.caldiy.idempotencycollision | One mutation key owns different input | Stop and inspect the original action |\n| connector.caldiy.inflight | A matching people mutation is executing | Read durable state and wait |\n| connector.caldiy.outcomeunknown | Prior provider dispatch cannot be proved | Reconcile; never create a speculative replacement key |\n| connector.caldiy.authentication | Provider returned 401 or 403 | Verify account binding, credential revision, booking ownership, and media authorization |\n| connector.caldiy.stateconflict | Provider returned 409 or 412 | Refresh booking or attendee state and review the requested change |\n| connector.caldiy.ratelimited | Provider returned 429 | Retry reads within current approval and policy; reconcile mutations |\n| connector.caldiy.remotetemporary | Provider returned a server error | Retry reads within policy; reconcile mutations |\n| connector.caldiy.transport | Provider exchange failed | Retry reads only; treat dispatched mutations as uncertain |\n| connector.caldiy.invalidprovideroutput | Successful response lacked a valid status | Preserve evidence and reconcile a mutation |\n\nPermanent provider rejection, invalid credentials, oversized responses, and\ndurable settlement failures use the common Cal.diy error family. Gateway and\nlifecycle errors are described in the global error reference (../../../reference/errors.md).\n\nVerify attendee or artifact handling\n\nFor attendee changes, verify the approval and idempotency key, wait for a\ncompleted durable result, then list attendees or read the exact attendee. For\nguest add, read the booking and compare only the intended guest change.\n\nFor artifact reads, verify the exact capability, booking uid, actor, tenant,\nexternal account, approval when required, response status, and data-handling\ndecision. Do not expose metadata merely because the operation completed.\n\nRetain the provider request id when present. Reconcile uncertain mutations and\nnever use a follow-up read as authorization to repeat a people-changing action.\n\nThese checks validate application handling. They do not prove notification\ndelivery, media accessibility, live-provider qualification, or production\nreadiness.\n\nRelated documentation\n• Cal.diy capability index (README.md)\n• Core booking capabilities (bookings.md)\n• Authentication and tenant routing (../getting-started/authentication-and-tenant-routing.md)\n• Transactions and compensation (../../../concepts/transactions-and-compensation.md)\n• Error reference (../../../reference/errors.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "f31d865efc0a2c96ca3f3e1392d736bbe5f4e66bd50a9a29eb78528692e65152"
  }
}