ScheduCal is a fully managed calendar invitation service built on Microsoft Exchange and the Microsoft Graph API. Customers integrate at the points in their code where they would send an email with an ICS file attachment — and instead call ScheduCal’s simple REST API.
Customer surface:
POST /api/v1/appointments to create an appointmentPUT /api/v1/appointments/{id} to update itDELETE /api/v1/appointments/{id} to cancel itThat’s the entire integration. ScheduCal handles everything behind the scenes.
ScheduCal’s delivery layer is Microsoft Exchange, accessed via the Microsoft Graph API. Exchange is not a workaround — it is the architecture.
When you call the ScheduCal API to create an appointment:
POST /me/events)When you update an appointment (PUT), Exchange sends a proper meeting update notification to all attendees — no re-sending of ICS files required. When you cancel (DELETE), Exchange sends a cancellation with the correct METHOD:CANCEL iTIP header.
Microsoft Exchange is the enterprise calendar standard:
Exchange delivers calendar invitations as standards-compliant ICS (iCalendar, RFC 5545) internally. ScheduCal ensures the correct RFC 5545 semantics are maintained across the full appointment lifecycle:
Every appointment has a single, persistent UID assigned at creation time. This UID is carried through all subsequent updates and the final cancellation. Per RFC 5545, the UID links all versions of an event (create, update, cancel) so attendee calendar clients can correctly correlate them.
If UID consistency breaks — a common mistake in DIY ICS implementations — calendar clients create duplicate appointments instead of updating the existing one.
The SEQUENCE property is incremented on every update per RFC 5545 §3.8.7.4. This tells attendee calendar clients that a newer version of the event has arrived, causing them to replace the old version rather than create a duplicate entry.
ScheduCal manages SEQUENCE automatically. Customers never need to track or pass a sequence number.
When an appointment is cancelled, ScheduCal issues a calendar message with METHOD:CANCEL per iTIP (RFC 5546). This is the correct mechanism for propagating a cancellation to attendee calendars — it removes the event from the attendee’s calendar rather than leaving a phantom entry.
Sending a plain cancellation email without the correct iTIP METHOD header is the most common implementation error in calendar invitation systems. ScheduCal handles this correctly.
When inviting a Gmail address for the first time from a given sending account, ScheduCal performs a Gmail priming step before sending the calendar invitation. This is required infrastructure, not an optional enhancement.
Why it exists: The Microsoft Exchange → Gmail calendar delivery path requires an initial email handshake to establish the sending relationship. Without this priming step, Gmail’s spam filters and calendar integration heuristics will frequently suppress the calendar invitation, and the event will not appear in the attendee’s Google Calendar.
What it does: ScheduCal sends a pre-invitation email to the Gmail address before the calendar invitation. This establishes trust between the sending Exchange account and the Gmail recipient, ensuring the calendar invitation lands correctly.
The gmailFirstInvite response field indicates when this priming step was executed. When gmailFirstInvite: true, you should display guidance to the attendee:
“Please check your spam folder and confirm the calendar invitation from ScheduCal.”
After the first successful invitation, subsequent invitations to the same Gmail address from the same account do not require priming (gmailFirstInvite: false).
Integrating directly with the Microsoft Graph API requires:
ScheduCal handles all of this. Your integration is three API calls and one webhook.
ScheduCal’s Exchange-based delivery works natively across:
| Calendar Client | Compatibility |
|---|---|
| Microsoft Outlook (365 / Exchange) | Native — full iTIP lifecycle |
| Google Calendar (Gmail) | Supported — Gmail priming required on first invite |
| Apple Calendar / iCloud | Supported — Exchange-native ICS delivery |
| Any CalDAV client | Supported — Exchange interoperates with CalDAV |