Automating Event Calendar Synchronization and Dispatch Operations Across Multi-Site Infrastructure
This session involved significant infrastructure consolidation and automation, integrating Google Calendar management across multiple business domains while establishing automated dispatch systems for field operations. The work demonstrates patterns for managing distributed event data and implementing reliable automation across loosely-coupled services.
Core Problem Statement
Multiple sites and business domains were operating with fragmented scheduling systems:
- Manual Google Calendar entry for recurring event holds (Sea Scout Wednesday blocks)
- Disconnected booking platform integrations (GetMyBoat, Boatsetter) without calendar sync
- Email-driven task management without automated confirmation workflows
- Boat cleaning operations requiring manual dispatch coordination
The session focused on consolidating these into API-driven automation layers, reducing manual touchpoints and improving data consistency across platforms.
Technical Architecture: Calendar Synchronization System
Google Apps Script Replacement Infrastructure
The primary system for calendar management lives in /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/apps-script-replacement/. The CalendarSync.gs file (deployed to Google Apps Script via Clasp) manages bidirectional calendar synchronization:
- Polling Interval: Every 15 minutes, the script checks for new bookings and platform events
- Email Notifications: Uses
GmailApp.sendEmail()for confirmation and error reporting - Calendar API Integration: Direct access to Google Calendar API for event creation/modification
- External Platform Hooks: Handles iCal feed polling from GetMyBoat and Boatsetter
The script was updated multiple times during this session to correct polling intervals and email destination addresses. The deployment process uses .clasp.json project mappings located in each site directory to route code to the correct GAS project ID.
Lambda-Backed Calendar API
For programmatic calendar operations beyond GAS capabilities, a Lambda function serves as a REST API endpoint:
- Function Name: Located in the dashboard infrastructure
- API Gateway Integration: v2 HTTP API with route-based action dispatch
- Actions Supported:
add-calendar-event,list-events,update-event - Authentication: Dashboard token-based auth (stored in
repos.env)
The Lambda function downloads event requests and interacts with Google Calendar API directly using stored service account credentials. This enables server-side event creation without exposing calendar permissions to client applications.
Dispatch and Automation: Boat Cleaning Operations
A new dispatch automation system was created to manage boat cleaning service coordination:
- Primary Script:
/Users/cb/Documents/repos/tools/dispatch_boat_cleaner.py - Purpose: Parses booking notifications and generates dispatch orders
- Integration Points: Reads from email inboxes via Gmail API, writes to task queue systems
- Deployment: Shell script wrapper at
/Users/cb/Documents/repos/tools/deploy_dispatch_boat_cleaner.sh
The dispatcher subscribes to booking platform webhooks (simulated via polling), extracts key details (date, location, boat ID), and creates time-stamped dispatch records that field operations can retrieve.
Campaign Scheduling Infrastructure
A secondary but important system handles marketing campaign distribution:
- Configuration:
/Users/cb/Documents/repos/tools/campaign_schedule.jsondefines templates, recipients, and timing - Scheduler Script:
/Users/cb/Documents/repos/tools/campaign_scheduler.pymanages queue and execution - Email Templates: HTML templates in
/Users/cb/Documents/repos/tools/templates/directory (separate templates for Rady Shell and other campaigns) - Deployment:
/Users/cb/Documents/repos/tools/deploy_campaign_scheduler.sh
This system decouples content management from delivery, allowing non-technical staff to modify templates without touching scheduling logic.
Site-Specific Implementations
quickdumpnow.com Operations Tooling
The QuickDumpNow site required specialized tools for consumer engagement:
- Blast Script:
/Users/cb/Documents/repos/sites/quickdumpnow.com/tools/qdn_consumer_blast.py— iterates through customer database and generates email content - Statistics Collector:
/Users/cb/Documents/repos/sites/quickdumpnow.com/tools/qdn_stats.py— aggregates opens, clicks, and conversion metrics - Templates: Located in
/Users/cb/Documents/repos/sites/quickdumpnow.com/marketing/templates/ - Unsubscribe Handling: Dedicated landing page at
/Users/cb/Documents/repos/sites/quickdumpnow.com/unsubscribe/index.htmlwith database sync
The consumer blast script went through multiple iterations to handle edge cases around customer segmentation and template variable substitution.
Key Architectural Decisions
Why Lambda for Calendar Operations?
Google Apps Script has execution time limits (6 minutes) and restricted scheduling. Lambda provides:
- 15-minute timeout capability for batch operations
- Direct CloudWatch logging and error tracking
- Fine-grained IAM permissions for service accounts
- Horizontal scaling for concurrent calendar updates
The split between GAS (for webhook-triggered, low-latency updates) and Lambda (for batch, high-volume operations) reflects these constraints.
Gmail API for Email Parsing
Rather than forwarding confirmation emails to custom processing addresses, the system uses Gmail API directly:
- Queries existing inbox with label filters (e.g.,
label:booking-confirmation) - Parses message bodies with regex patterns specific to each booking platform
- Maintains audit trail within Gmail labels rather than separate databases
This reduces infrastructure surface area and avoids setting up custom mail parsing infrastructure.
Polling Over Webhooks
The platform inbox scraper (/Users/cb/Documents/repos/tools/platform_inbox_scraper.py) uses polling rather than requesting webhook setup with third-party platforms:
- Simpler for platforms without webhook support (some older booking systems)
- Easier to debug (can replay historical emails)
- No external endpoint exposure required
- Trade-off: 15-minute polling interval acceptable for non-urgent updates
Infrastructure Changes and Deployment
No CloudFormation or Terraform changes were