Unified Calendly Trigger Architecture

Polling-based ingestion · 6-stage pipeline · 7 consuming OS modules · 1 canonical contract

One poller · one contract · every OS module subscribes

Calendly exposes no webhook on the Base44 connector, so a single scheduled poller diffs /scheduled_events against last-seen state, normalizes each change into the canonical CalendlyTriggerEvent, resolves a routing table, and fans the trigger out to every consuming OS module on the event bus. No consumer calls Calendly directly — the poller is the only ingress.

Trigger pipeline

poll → normalize → diff → route → fan-out → consume
01

Ingestion

Scheduled automation polls Calendly REST API on a fixed interval (no webhooks — polling only).

02

Normalize

Raw Calendly payloads mapped to the canonical CalendlyTriggerEvent contract.

03

Dedup & State

Diff against last-seen event URIs to detect created / canceled / rescheduled / completed.

04

Route

Event-type → OS module routing table (config-driven, tenant-aware).

05

Fan-Out

One confirmed trigger dispatched to every matching consumer on the bus.

06

Consume

OS modules react: create InterviewSchedule, enrich Lead, schedule Event, notify, etc.

Trigger event types

detected by diffing — not pushed
active

Meeting Scheduled

meeting.scheduled

New event URI appears in /scheduled_events diff

canceled

Meeting Canceled

meeting.canceled

Previously-seen URI now has status=canceled

active

Meeting Rescheduled

meeting.rescheduled

Same URI, start_time changed beyond threshold

past

Meeting Completed

meeting.completed

end_time passed with status=active

past

No-Show Detected

no_show.detected

Completed meeting with invitee status=inactive

Routing rules

event-type pattern → consumer set
event_type.name contains "Employer Interview"
event_type.name contains "Onboarding"
event_type.name contains "Partner"
event_type.name contains "Consultation" + invitee is new lead
event_type.name contains "Event" / "Session"
default (no pattern match)

Consuming OS modules

7 subscribers

Canonical contract · CalendlyTriggerEvent v1

fieldtypedescription
trigger_idstringStable hash of Calendly event URI (dedup key)
event_typeenummeeting.scheduled | canceled | rescheduled | completed | no_show.detected
calendly_event_uristringCalendly scheduled_event URI
event_type_uuidstringCalendly event_type UUID (routing key)
event_type_namestringHuman label of the Calendly event type
invitee_emailstringInvitee email (PII — encrypted at rest)
invitee_namestringInvitee name
invitee_phonestringInvitee phone (optional)
start_timedatetimeMeeting start (ISO 8601)
end_timedatetimeMeeting end (ISO 8601)
locationstringzoom | phone | in_person | google_meet
statusenumactive | canceled
assigned_tostringCalendly user that owns the event
tenant_idstringTenant scope (FK DualPartner)
metadataobjectCustom question answers (key/value)
detected_atdatetimeWhen the poller detected this change
producerstringcalendly-poller
consumersstring[]Resolved OS module IDs to dispatch to
correlation_idstringLinks poll cycle → trigger → consumer reactions

Event-bus flows

calendly_api
GET /scheduled_eventsCalendly REST
ingest
ingest
raw.payloadCalendly JSON
normalize
normalize
calendly.trigger.candidateCalendlyTriggerEvent
dedup
dedup
calendly.trigger.confirmedCalendlyTriggerEvent
route
route
calendly.trigger.routedCalendlyTriggerEvent + consumers[]
fanout
fanout
calendly.trigger.dispatchedCalendlyTriggerEvent
consume

Implementation artifacts

Backend function · calendlyTriggerPoller

Polls /scheduled_events, diffs against stored state, emits CalendlyTriggerEvent records.

Scheduled automation (every 5 min)

create_automation automation_type="scheduled" → calendlyTriggerPoller. Minimum 5-min interval.

State store · OrchestratorState

Last-seen event URIs + cursor per Calendly user; powers dedup & reschedule detection.

Backend function · calendlyTriggerDispatch

Reads confirmed triggers, resolves routing rules, fans out to consumer functions.

Connector · calendly (SHARED)

Builder authorizes once via request_oauth_authorization; token used server-side only.

Metrics · PlatformMetric + AuditLog

Trigger volume, latency, no-show rate, routing failures — all auditable.