Build a reminder from an active Calendly invitee booking, then cancel or replace that pending reminder when the invitee cancels or reschedules. Send the message through IllyVoIP only after checking the current booking. The reminder queue belongs to your application; this is not a native Calendly connector inside the Portal.
Before you connect the workflow
You need Calendly API/webhook access permitted by your current plan and account role, a private HTTPS receiver, durable storage and a scheduler. Check the current subscription and token scopes rather than assuming every free or team account has the same access. Prepare an IllyVoIP key, allowed sender and a clear permission policy for booking notifications.
Collect an appropriate phone number and notification choice during your own booking process. A phone-shaped answer in a custom question does not by itself establish consent or an international country code. If the number is absent or ambiguous, mark the reminder for review instead of substituting the organiser’s number.
1. Subscribe and verify the incoming events
- Create the appropriate Calendly webhook subscription for
invitee.createdandinvitee.canceled, with the user or organisation scope your integration is authorised to manage. - Keep the webhook signing key private. Verify
Calendly-Webhook-Signatureagainst the original body, using its timestamp and v1 signature as described by Calendly. - Use a deliberate timestamp tolerance with a synchronised server clock and a constant-time HMAC comparison. Do not reuse the Xero body-only signature format.
- Validate the expected account scope, persist the event durably and acknowledge promptly. An invalid signature must not schedule or cancel any reminder.
2. Store the invitee identity and schedule
Use the invitee URI as a stable booking-attendee identity and retain its scheduled-event URI. Store the event start instant, relevant timezone, invitee status, chosen recipient and reminder policy. For group events, several invitees share one scheduled event; do not collapse them into a single recipient record.
Compute the reminder from an actual timezone-aware start instant. For example, a reminder one day before a booking is not safely computed by comparing a free-text “tomorrow” string. Decide what happens if the booking is created after your reminder window has already passed. Store a schedule revision so a queued older job can be rejected before dispatch.
3. Apply cancellation and rescheduling correctly
On invitee.canceled, cancel the unsent reminder for that invitee. A reschedule can produce cancellation of the old invitee and creation of a new one. The cancellation’s rescheduled flag and the invitee’s old_invitee/new_invitee relationships help connect the change. They belong to the invitee model, not to an invented event-level reschedule field.
Do not assume both notifications arrive once or in the order you expect. Reconcile the old and new invitee resources, mark the old pending schedule obsolete and create at most one valid reminder for the new active invitee. A late old “created” event must not reactivate a booking already cancelled. Preserve a tombstone or revision record so that stale events can be rejected.
4. Recheck before sending
- Claim the due reminder once in durable storage and check its current revision.
- Read the relevant Calendly event/invitee resource using the authorised account. Confirm the invitee is still active and the intended start time has not changed.
- Recheck recipient permission, exclusions and the reminder window. If the read fails, defer and reconcile instead of treating the old snapshot as current.
- Build a concise message with an unambiguous local date/time and approved booking-management link when available. Avoid private meeting credentials or internal notes.
5. Send and follow the IllyVoIP message
POST JSON to /api/v1/sms/messages on the HTTPS host api.illyvoip.com with X-Api-Key and a persisted Idempotency-Key. Send from, a one-recipient to array and message. Keep the key and exact payload with that reminder revision. Reuse them only for the same submission; regenerating a key on every worker retry can create multiple messages.
Store the accepted message ID and process immediate rejection as well as later delivery status. Do not send a “replacement” merely because a delivery webhook has not arrived. A cancellation after an SMS was already accepted cannot be treated as an unsent reminder; record that boundary and use your explicit customer-notification policy if another message is needed.
6. Test the lifecycle before enabling the schedule
Exercise a normal booking, duplicate events, cancellation, reschedule with reversed event order, a timezone/DST transition, a missing phone number and an interrupted send response. Verify that the old schedule is suppressed and only the current authorised intent can send. These tests can use local fixtures; a separate permitted account test is needed to confirm your Calendly subscription and actual SMS delivery. Keep tokens, attendee details and webhook payloads private.
Related guides
- Build appointment SMS reminders with IllyVoIP
- Send Google Calendar event reminders through IllyVoIP SMS
- Send an SMS with the IllyVoIP API and track delivery
- Troubleshoot webhook delivery
Reference
Current instructions and technical reference: Calendly rescheduling events, Calendly webhook signatures, Calendly API access questions.
Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.