A recurring webinar is not one event
Every weekly occurrence has its own identity. Registration and reporting must resolve the intended occurrence—not assume the permanent webinar ID is enough.
6MTS · Implementation & operations manual · v1.1
Webinar Attendance Tracking
How to build, operate, test, and hand off the recurring Zoom → GHL system.
Use this manual to take over the technical integration, decide whether the existing connector is salvageable, and certify the complete weekly workflow before assigning any downstream GHL work.
AudienceIntegration owner / operator
Operating modelRegistration + attendance jobs
State modelExternal session ledger
Launch gateTwo passing cycles
How to use this manual
Start with the takeover audit. Do not begin by building GHL workflows.
First, obtain the existing source, runtime access, logs, schedules, credentials, and proof from prior runs. Test the connector against the required data contract and failure paths in this manual.
If the existing code passes the audit, use the 20–35 hour hardening track. If its state model, occurrence handling, retries, or monitoring cannot be verified, use the 40–70 hour rebuild track. Configure the GHL communication layer only after the technical handoff passes.
01 · Design rules
Requirements to satisfy before implementation
Treat these as system requirements and use them during the initial takeover audit.
Tags are not attendance history
Permanent attended/no-show tags become stale, can coexist, and may not retrigger the next week. Weekly state needs a session key and an event-based trigger.
Reruns must be safe
A retry cannot create another Zoom registrant, overwrite the wrong link, or send the same reminder twice. Every write needs an idempotency rule.
Write order matters
GHL must receive the join URL and session data before the event that starts a workflow. Otherwise messages can fire with blank or stale values.
Authentication will fail eventually
OAuth, private tokens, scopes, app changes, and revoked access require a named owner, health checks, and an explicit recovery procedure.
Silent failure is the real risk
A scheduled script that stops running can look healthy until contacts miss reminders. Monitoring, reconciliation, and alerts are part of the product.
02 · Corrected architecture
One pipeline, two controlled handoffs
Registration and attendance are separate jobs. Both pass through a durable ledger before they release a GHL workflow event.
1GHL
Capture opt-in
A contact submits the masterclass form. GHL records consent and the registration source.
2Integration
Queue the job
Create one idempotent registration job keyed to the contact and upcoming session.
3Zoom
Resolve occurrence
Resolve the exact upcoming occurrence ID and scheduled start time before registration.
4Integration
Register and persist
Register the contact, capture the registrant ID and unique join URL, then write the ledger.
5GHL
Publish the handoff
Write session fields first. Write a unique registration event ID last to release downstream messaging.
6GHL
Send reminders
GHL runs approved reminder workflows with exclusions, send windows, and DND safeguards.
7Zoom
Read the ended session
After the webinar, resolve the completed occurrence UUID and retrieve that instance’s participant data.
8Integration
Reconcile and publish
Match attendees to registrants, classify exceptions, update the ledger, and publish a unique attendance event to GHL.
Critical release rule
Write data fields first. Write the unique event ID last. GHL workflows listen for that event ID to change, then read the already-complete data.
03 · Canonical data contract
Make weekly state explicit
GHL holds the current messaging state. The integration ledger holds the auditable session history and retry state.
GHL contact fieldsDownstream contract
mc_session_keyTextStable key for the weekly occurrence, such as 2026-07-28_86742848573.
mc_occurrence_idTextZoom occurrence identifier used for that registration.
mc_occurrence_uuidTextEnded webinar instance UUID used for attendance reporting.
zoom_join_urlText / URLUnique per-contact join link. Written before the registration event fires.
mc_registration_event_idTextNew UUID for each completed registration handoff. GHL trigger field.
mc_attendance_statusDropdownattended, no_show, unmatched, or review_required.
mc_attendance_event_idTextNew UUID for each completed attendance handoff. GHL trigger field.
mc_attended_minutesNumberNormalized total attendance duration for the resolved occurrence.
mc_last_synced_atDate/timeUTC timestamp for support and reconciliation.
04 · Operating procedures
Run the system the same way every week
The implementation owner should turn these procedures into scheduled jobs and preserve them in the operator runbook.
Procedure A
Registration sync
Every 15–30 minutes- Select opted-in contacts that do not yet have a successful ledger record for the upcoming session.
- Resolve the exact upcoming Zoom occurrence and build the session key.
- Claim the idempotency key before making any external write.
- Register the contact in Zoom and capture the registrant ID and unique join URL.
- Persist the complete Zoom response in the external ledger.
- Write session, occurrence, join-link, and sync fields to the matching GHL contact.
- Write a new registration event ID last to release the GHL reminder workflow.
- Reconcile selected, registered, released, skipped, and failed counts; alert on any unexplained difference.
Procedure B
Attendance sync
After each Tuesday webinar- Identify the scheduled session and resolve the UUID for that specific ended occurrence.
- Wait until Zoom reporting data is available; retry report-not-ready responses with bounded backoff.
- Fetch every participant page and preserve the raw response for audit.
- Merge repeat joins for the same participant and calculate normalized attendance minutes.
- Match participant records against that session’s registration ledger.
- Classify every registration as attended, no_show, unmatched, or review_required.
- Write attendance status, minutes, occurrence UUID, and sync timestamp to GHL.
- Write a new attendance event ID last to release the correct downstream workflow.
- Reconcile all registered contacts to a final state and publish an exception report.
Procedure C
Safe replay
When a run partially fails- Pause downstream messaging if the failed run could release incomplete data.
- Locate the exact session and affected ledger records; never replay an unbounded date range.
- Correct the root cause—credentials, occurrence selection, contact matching, or API availability.
- Replay only records that are not already marked successful for that operation.
- Reuse the existing Zoom registration when it exists; do not create a second registrant.
- Generate a new GHL event ID only when a completed handoff still needs to be released.
- Compare before/after counts and attach the replay result to the incident record.
Operator failure codesRequired runbook responses
AUTH_FAILEDZoom or GHL rejected the credential
Stop the affected job, alert the owner, rotate/reconnect, then replay the scoped records.
OCCURRENCE_NOT_FOUNDThe intended weekly occurrence cannot be resolved
Do not fall back to the latest session. Require schedule review or manual selection.
REPORT_NOT_READYThe webinar ended but Zoom reporting is not available
Retry with bounded backoff; do not mark registrants as no-shows yet.
CONTACT_UNMATCHEDA Zoom record cannot be mapped confidently to GHL
Quarantine for review. Never guess between duplicate contacts.
PARTIAL_HANDOFFSome GHL fields saved but the workflow event did not
Verify field completeness, then release one new event ID without re-registering.
RECONCILIATION_DRIFTRegistration and final-state totals do not balance
Block certification, produce an exception list, and resolve every unexplained record.
05 · Step-by-step build plan
Eight phases to production
The estimate assumes competent API implementation, existing paid Zoom webinar access, and timely access to both accounts.
Phase 03–5 h
Ownership, access, and final design
Integration owner + 6MTS- Confirm the webinar registration type and weekly scheduling model.
- Choose the integration runtime and durable state store.
- Document Zoom/GHL accounts, scopes, owners, and credential rotation.
- Lock the field contract, trigger strategy, timezone, privacy, and retention rules.
Exit gate: Signed architecture and access checklist.
Phase 15–8 h
Zoom authentication and occurrence resolver
Integration owner- Configure a supported Zoom app with the required webinar and reporting scopes.
- Resolve the next scheduled occurrence before registration.
- Resolve the ended occurrence UUID before attendance reporting.
- Handle UUID encoding, pagination, rate limits, revoked access, and reschedules.
Exit gate: A test can identify both the upcoming and most recently ended occurrence.
Phase 28–12 h
State ledger and registration worker
Integration owner- Create the external session/registrant ledger and unique constraints.
- Search GHL using supported APIs and normalize contact identity.
- Register each contact once per session and persist the Zoom response.
- Make retries idempotent and quarantine partial or unmatched records.
Exit gate: New, existing, and repeat-week registrants process without duplicates.
Phase 34–6 h
GHL data contract and workflow release event
Integration owner- Create and document the agreed contact fields.
- Write session/link fields first and the unique event ID last.
- Use field-change events or direct workflow enrollment—not permanent tags as the event source.
- Preserve tags only as optional, human-readable views of current state.
Exit gate: A completed handoff reliably releases one—and only one—GHL workflow event.
Phase 48–12 h
Attendance reconciliation
Integration owner- Wait until the target occurrence has ended and reporting data is available.
- Pull all participant pages for the exact occurrence UUID.
- Merge repeat joins, normalize attendance minutes, and match against the ledger.
- Classify attended, no-show, unmatched, duplicate, and review-required records.
Exit gate: Registered totals reconcile to an explicit final status with an exception report.
Phase 54–8 h
Monitoring, security, and operator runbook
Integration owner- Add alerts for auth failures, API failures, job silence, and reconciliation drift.
- Create a safe manual replay/backfill path for one session or contact.
- Restrict join URLs and contact data; do not post full sensitive links into broad Slack channels.
- Document dashboards, schedules, credentials, recovery, escalation, and data retention.
Exit gate: A named operator can detect, diagnose, and replay a failed run.
Phase 64–8 h
GHL messaging workflows
GrowProfit — bounded scope only- Build or update static reminder workflows with client-approved copy and timing.
- Apply existing-client exclusions, DND rules, send windows, and stop conditions.
- Test only the actions and conditions configured directly in GHL.
- Treat dynamic links or integration-driven nurture as a separate written scope.
Exit gate: Designated test contacts receive the approved GHL-native messages correctly.
Phase 76–10 h
QA and live-cycle certification
Integration owner + 6MTS- Run the full test matrix in a safe environment.
- Observe at least two consecutive weekly webinar cycles.
- Compare Zoom, ledger, GHL, and message counts after each cycle.
- Close all exceptions and deliver the final handoff packet.
Exit gate: Two consecutive cycles pass the acceptance criteria without manual data repair.
Applies only when source access, runtime access, logs, state, occurrence handling, and a successful proof run are available. Covers audit, corrections, monitoring, runbook, and certification support.
Applies when the connector lacks trustworthy state, occurrence-aware processing, idempotency, reconciliation, monitoring, or recoverable deployment. This range matches the eight phases above.
Both tracks normally span 2–3 calendar weeks because attendance cannot be certified until real webinar occurrences finish. Waiting time is not engineering time.
06 · QA and acceptance
Test the failure paths, not just the demo
A single happy-path contact is not sufficient evidence that a recurring attendance system is production-ready.
Required test matrix
- Brand-new GHL contact
- Existing GHL contact
- Same contact registering for a later week
- Worker rerun after partial success
- Zoom 429 / transient 5xx response
- Expired or revoked credential
- Webinar rescheduled or canceled
- Attendee joins more than once
- Registered contact does not attend
- Zoom participant cannot be matched
- Current-client exclusion
- Missing join URL before workflow release
07 · Ownership boundary
Who owns what after launch
The system stays supportable only when the runtime and integration have a named technical owner.
Owns the technical system
- Zoom/GHL authentication and scopes
- Occurrence resolution and API implementation
- Ledger, registration, attendance, retries, and monitoring
- Dynamic join links and field population
- Outages, backfills, data correction, and ongoing maintenance
Owns business inputs and approval
- Account access and vendor authorization
- Approved copy, schedule, destinations, and exclusions
- Consent, privacy, retention, and internal data access
- Live-cycle review and acceptance signoff
Can own a bounded GHL layer
- Static reminder workflows using approved inputs
- Copy, wait steps, send windows, and existing exclusions
- Testing of actions configured directly by GrowProfit in GHL
- Any integration-driven or dynamic-link work only under a separate written scope
08 · Final deliverable
Clean handoff packet
The project is not handed off when the script runs once. It is handed off when another qualified operator can support it without guessing.
01
Source repository and deployment/runtime owner
02
Environment and credential inventory with rotation instructions
03
Architecture diagram and exact field/data dictionary
04
Occurrence-resolution and idempotency rules
05
Monitoring links, alert destinations, and failure thresholds
06
Manual replay, backfill, and reconciliation runbook
07
Two successful cycle reports with exception counts
08
Named primary and backup technical owners
Completion standard
The takeover is complete when another operator can run and recover the system from this manual.
After the technical owner completes the applicable track and certifies two weekly cycles, GrowProfit can evaluate a narrow GHL workflow scope. Connection troubleshooting, dynamic links, attendance logic, and technical support remain part of the integration owner’s runbook.