Group Scheduling API: Verify Every Invitation Before Reporting Booked

Build invitation verification into the booking path in eight steps

Use one hard meeting with four required people, two optional people, Google and Microsoft calendars, one unconnected participant who supplied a bounded window, one conference link, duplicate booking delivery, and a hidden response after the provider write.

1. 1

   Define completion in the meeting-intent schema

   Persist authenticated organizer, purpose, duration, bounded date range, chosen IANA zone, required and optional participant entities, approved substitutes, organizer calendar, location or conferencing policy, disclosure, approval mode, and terminal proof. State which facts must be verified before the API may return confirmed.
   • Every required human has one participant identity independent from an attendee string.
   • Optional inclusion or exclusion is explicit in the approved revision.
   • A proposal, hold, poll winner, or provider request is never terminal success.
2. 2

   Build the proposal from current connected and conversational evidence

   Read approved Google and Microsoft free/busy, then collect bounded availability from anyone who does not connect a calendar. Normalize identity, source, IANA zone, retrieval or reply time, consent, freshness, expiry, and provider errors. Intersect every required person before ranking optional attendance and preferences.
   • Calendar connection remains optional and helpful.
   • Missing access, silence, and stale evidence remain unknown rather than free.
   • The proposal records the exact evidence versions that produced it.
3. 3

   Bind approval to one immutable booking command

   Capture meeting ID, revision, proposal ID, exact start and end, IANA zone, organizer calendar, required participant IDs, selected attendee addresses, optional decisions, conferencing policy, disclosure, and approver authority. Derive one booking operation identity from that approved tuple and reject stale approvals.
   • A participant or calendar change invalidates the old command.
   • Repeated client and worker delivery resolve to one logical booking.
   • Booking, rescheduling, and cancellation use separate authorized commands.
4. 4

   Re-check required availability immediately before the write

   Refresh every required connected calendar and confirm conversational evidence is still current. Re-run hard constraints, time-zone conversion, buffers, consent, and approval expiry. If the approved slot changed materially, return proposal-stale rather than writing first and apologizing later.
   • Optional attendance cannot rescue a collision for a required person.
   • The chosen local times still match the approved IANA zones across daylight-saving boundaries.
   • Provider read errors pause the affected write instead of being treated as free time.
5. 5

   Write one canonical event and persist provider identities

   Create the event on the approved organizer calendar with the exact time, zone, required attendee addresses, approved optional attendees, and conferencing or location data. Persist provider, calendar, event, recurring-series or occurrence identity, operation key, response, notification policy, and side-effect state outside the model loop.
   • Notification behavior is explicit rather than an unchecked SDK default.
   • The organizer event is distinguishable from attendee copies.
   • A timeout enters unknown-write-state and does not trigger a blind second create.
6. 6

   Reconcile uncertain responses before retrying

   When the create response is missing or ambiguous, query the exact organizer calendar using stored operation and provider identities. Classify event-present, event-absent, duplicate, moved, permission-lost, attendee-mismatch, or unknown. Retry only the same authorized command after evidence says no equivalent event exists.
   • A timeout is not assumed to mean failure.
   • Duplicate events become repair work before any success response.
   • Retries cannot expand participants, disclosure, time, or calendar scope.
7. 7

   Read back a completion manifest from provider truth

   Fetch the canonical event and verify organizer, calendar, start, end, IANA zone, duration, event status, every required attendee address, approved optional decision, conferencing or location, and invitation-notification policy where the provider exposes it. Map addresses back to participant entities and preserve provider-specific limits as explicit unknowns.
   • One missing required attendee keeps the meeting out of confirmed state.
   • A correct attendee count cannot hide the wrong intended human.
   • The API distinguishes verified provider fields from inferred delivery claims.
8. 8

   Repair mismatches and return one honest terminal result

   For a safe deterministic mismatch, issue a versioned repair under the original authority and verify again. Route identity, permission, disclosure, organizer, time, or participant-scope conflicts to a named human owner. Return confirmed with the completion manifest only after proof; otherwise return a bounded state with evidence, next action, and retry policy.
   • The result identifies verified, unknown, and failed completion fields separately.
   • All participant outreach, reminders, proposals, writes, repairs, and read-backs share one trace.
   • Terminal proof survives model, worker, and provider restarts.

Compare booking systems by what they can prove

The production boundary is not event-created. It is one authorized meeting whose final provider state agrees with the approved participant contract.