Sync database items.
Your schedule lives in Google Calendar, your work lives in Notion, and the two never quite agree. No-code sync tools promise to bridge them, then quietly go one-way, drop recurring events, or leave orphaned rows behind when you delete something. Strip away the marketing and a calendar and a database are just two lists that need to stay equal. The honest version is a script you can read and trust, and this blueprint writes it as code you own.
A sync script that keeps Google Calendar events and a Notion database in agreement in both directions. It pulls events into Notion rows, pushes changes back the other way, and handles the two cases most integrations botch: updates, where an event that moved refreshes its existing Notion row instead of duplicating it, and deletions, where a removed event clears its counterpart instead of leaving a stale entry. The bi-directional reconciliation keeps either side from drifting.
You watch it happen in the task workspace: the agent scaffolds the project, wires the Calendar and Notion API calls, and runs a test sync to confirm events and rows line up and a deletion propagates. The code lands on a branch in your repository with a pull request ready.
The first version is a foundation you steer with plain follow-up messages:
Each follow-up wakes the same repository and the agent continues on its own code.
Do I need API access to both services? Yes, it runs on your own Google and Notion credentials, so nothing routes through a third party.
What about recurring events? They're the classic sync trap. Ask the agent to expand a recurring series into individual rows and it handles the edge cases.
Will running it twice create duplicates? No, records are matched by ID before anything is created, so a re-run reconciles the two sides instead of doubling them.