Job calendar-booking-sync-to-google-calendar · revised 11 October 2026
Put each booking from your app on a Google Calendar, and keep changes in step
A booking created, moved or cancelled in your app creates, moves or removes exactly one event on one Google Calendar at the right local time, however many times the job runs.
You might be seeing
- Staff copy bookings into Google Calendar by hand and sometimes forget or mistype the time
- A rescheduled booking leaves the old event behind, so the calendar shows two
- Events appear an hour out after the clocks change, or at the server's time rather than the customer's
No passwords, keys, card details or admin invites needed to start.
What usually happened
A booking is data in your app and an event in Google Calendar, and the two must be tied together by a stable identity. Without one, a retried job creates a second event, a change creates a new event instead of moving the first, and a cancellation leaves a ghost. Times fail when the event is built from a time without its time zone, and a connection stops working when the Google authorisation lapses.
Who it’s for: A founder or service-business owner whose own booking tool or form stores appointments in a database, and whose staff want them on a Google Calendar instead of retyping each one.
Usually starts when: Appointments are being copied into a calendar by hand and some are missing or at the wrong hour, or an earlier sync created duplicate events and double-booked staff.
The result: Three agreed test bookings, including one in another time zone and one across a clock change, appear on the named Google Calendar at the expected local times. Re-sending a booking never creates a second event, a move changes the same event, a cancellation removes it, and a revoked connection is reported without losing the booking.
Check whether this job fits
Answer from what you know about your booking data and Google set-up. It needs no tokens or calendar access.
Checks you can run yourself
Find the time zone of three real bookings
Open three recent bookings in your admin screen and note the date, time and any zone or location shown for each. Do not copy customer names.
Look for: Whether the zone is stored or only implied by the server. If it is only implied, say so; it decides how the test cases are built.
What you get
- A pull request with the sync module, the identity rule, time handling, the missed-booking list and tests
- A table of the three test bookings with expected and observed calendar times
- A note that explains the authorisation set-up and what lapses it
- Undo steps
Included
- One-way sync from your app to one named Google Calendar for create, reschedule and cancel of one booking type
- A stable event identity derived from the booking so a repeated job finds the event it already made, using the identifier format that Google specifies
- Event times written with an explicit IANA time zone from the booking, tested across a clock change
- Authorisation using your own Google Cloud project and the narrowest calendar permission that works, with a clear reconnect state when access lapses
- A list of bookings that did not reach the calendar, and one admin action to send them again
Not included
- Reading the calendar back: availability checks, blocking booked slots and two-way sync are a separate job
- Outlook, Microsoft 365 or Apple calendars
- Inviting customers, sending calendar emails or creating video-meeting links unless agreed in writing
- Recurring bookings and shared resource scheduling
- Google's app verification and consent-screen review, which your account holder completes
- Building the booking tool itself
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each of the three agreed test bookings creates exactly one event on the test calendar whose start and end, shown in the calendar's own display, match the expected local times written before the test.
Evidence: A table of expected against observed times and screenshots of the three events.
Running the create job a second time for the same booking, and replaying a booking whose first attempt failed after the event was made, leaves exactly one event.
Evidence: Test output and a count of events for that booking before and after.
Moving a booking changes the same event, and cancelling it removes it from the calendar.
Evidence: The event identity before and after each change, and a screenshot of the calendar after cancel.
After the app's access is revoked in the Google account, a new booking is still saved, appears in the missed-booking list and the app shows a reconnect state; after reconnecting, the admin action sends it once.
Evidence: The list before and after reconnect and the single resulting event.
Sign-off. You read the time table, the screenshots and the test output, then sign off in writing and merge. Payment follows sign-off; your team deploys and completes the production Google authorisation.
If it fails. If the agreed checks do not pass you do not pay for this fixed scope. If the cause is your Google project settings, booking data without time zones or an excluded two-way need, we explain the evidence and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- Bookings are stored in your own database with a stable ID, a start, an end and a time zone or a location from which the zone is known
- You have a Google Cloud project and a Google account that owns the target calendar, and a person who can complete the consent screen
- The app can run a staging copy that writes to a test calendar you create
- Your maintainer can review, merge and deploy the change
We stop and tell you if
- The booking data has no reliable time zone and one cannot be agreed, so correct local times cannot be shown
- Google access would stay in a mode where the authorisation expires after about a week and nobody will change the project settings
- The job really needs availability from the calendar to drive the booking form, so we quote a two-way scope
- Nobody on your side can complete the Google authorisation
What could go wrong
Before merge, closing the pull request changes nothing. After merge, reverting the commit stops new events; events already made stay on the calendar until you delete them, and you can revoke the app's access from your Google account at any time.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Events show at the wrong hour around a clock change or for another time zone. | Each event carries an explicit time zone from the booking, and the test set includes a clock-change case with expected local times written down first. |
| A retried job creates a second event, or a created event is lost. | A stable event identity is derived from the booking, tests repeat every operation, and a missed-booking list shows anything that did not arrive. |
| Access lapses and bookings stop syncing silently. | A visible reconnect state and the missed-booking list; the booking itself is always saved first. |
A reviewer separate from the builder checks the diff, the event identity rule, the time-zone handling and that no token or client secret is logged. Your authorised maintainer merges, and you complete the production authorisation.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the booking type, calendar, event fields, time-zone source and who completes the Google consent
- Read how bookings are created, changed and cancelled and where a sync can run after the booking is safely saved
- Build the identity rule, event writer and time handling on a branch, with tests for create, repeat, move and cancel
- Build the missed-booking list and the reconnect state for lapsed access
- Run the three agreed test bookings against a test calendar and compare the observed times with the expected table
- Have an independent reviewer check the diff and evidence, then hand over with undo steps
An enquiry books nothing and charges nothing. Scope, access route and checks are agreed in writing first.
Need to keep it working?
If bookings are business-critical, ask about the monthly service that checks the connection, credentials and quotas.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your developer can follow Google's guide to creating events, which describes supplying your own event ID to avoid duplicates after a failed call. developers.google.com
- Some booking tools include a calendar connection; check whether yours can write to Google Calendar before commissioning custom work.
Questions
Can the calendar also block times on my booking form?
Not in this job. That needs reading the calendar back, which is a separate two-way scope.
Why do I need my own Google Cloud project?
The authorisation to your calendar should belong to you and be revocable by you. A shared app would put your calendar behind someone else's account.
What stops duplicate events?
Each event gets an identity derived from the booking, so a repeated job finds the event it already made and updates it.
Does it work with Outlook?
No. Microsoft calendars use a different service and need their own scope.
Send an enquiry
Send us
- The app's language and framework, and where bookings are stored
- The booking fields that should appear in the event title and description, without real customer data
- Whether the Google account is a personal one or a Workspace account, and the usual time zones involved
- Do not send Google passwords, tokens, client secrets, customer bookings or code in the first enquiry
Later, once you agree
- Read access to the code through a company-controlled repository or export, and a staging environment you control
- A Google Cloud project, OAuth client and test calendar that you create; the client secret stays in your secret store
- Three synthetic bookings including your own time-zone and clock-change cases
- A person who can complete the consent step on the day of the live test
You own the Google account, the Google Cloud project, the OAuth client and every token. We work on a branch through a company-controlled identity and use a test calendar you create. The production authorisation is completed by you after merge.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “calendar-booking-sync-to-google-calendar” as the subject.