{"slug": "event-reminders-from-an-agent-s-calendar", "title": "Event Reminders From an Agent's Calendar", "summary": "Nylas published a recipe for building an event reminder system using its Calendar API. The system fetches events via a single API call, filters out all-day, cancelled, and organizer-only events, and sends email reminders to external participants. It supports Google Calendar, Microsoft, and Exchange without provider-specific code, and can be paired with Agent Accounts for dedicated reminder addresses.", "body_md": "An entire appointment-reminder system hangs off this one request:\n\n```\ncurl --request GET \\\n  --url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/events?calendar_id=<CALENDAR_ID>&start=1700000000&end=1700086400&limit=50' \\\n  --header 'Authorization: Bearer <NYLAS_API_KEY>'\n```\n\n`start`\n\nand `end`\n\nare Unix timestamps in seconds, so that's \"every event in the next 24 hours\" in a single call. Run it on a cron every 15 minutes, filter out events that don't deserve a reminder, email the attendees who do, and you've replaced the reminder feature that calendar apps never built — because built-in notifications only reach the event's *owner*, not the patient, student, or prospect on the other side.\n\nThe [event reminder recipe](https://developer.nylas.com/docs/cookbook/use-cases/act/schedule-event-reminders/) walks the whole thing end to end, and it runs across Google Calendar, Microsoft, and Exchange with no provider-specific code. Pair it with an [Agent Account](https://developer.nylas.com/docs/v3/agent-accounts/) — in beta — and the reminders come from a dedicated address whose calendar the agent owns outright, instead of borrowing a human's grant.\n\nNot every event in the window should trigger an email. The recipe's filter skips three categories:\n\n`when.object`\n\nset to `\"timespan\"`\n\n; all-day ones use `\"date\"`\n\nor `\"datespan\"`\n\nwith date strings. Holidays and OOO blocks don't need reminders.The organizer also gets excluded from the recipient list. Nobody needs a reminder about the meeting they created. Cancelled events get skipped too — the `status`\n\nfield on each event tells you whether it's still confirmed, and reminding someone about a dead meeting is worse than no reminder at all.\n\nIn code, the whole filter is about a dozen lines:\n\n``` js\nconst sentReminders = new Set(); // use a database in production\n\nfunction shouldSendReminder(event) {\n  if (sentReminders.has(event.id)) return false;\n\n  // All-day events use \"date\"/\"datespan\" instead of \"timespan\"\n  if (event.when?.object === \"date\" || event.when?.object === \"datespan\") {\n    return false;\n  }\n\n  if (event.status === \"cancelled\") return false;\n\n  // Calendar holds with only the organizer aren't meetings\n  return getExternalParticipants(event).length > 0;\n}\n\nfunction getExternalParticipants(event) {\n  return (event.participants || []).filter(\n    (p) => p.email !== process.env.ORGANIZER_EMAIL,\n  );\n}\n```\n\nThe in-memory `Set`\n\nis fine for a prototype and a bug in production: it resets on every restart, and your attendees get re-reminded after each deploy. The recipe's recommendation is a database keyed by event ID with a timestamp — and, smarter still, a hash of the key fields (time, title, participants) so you can tell \"already reminded\" apart from \"event changed enough to deserve a fresh notification.\"\n\nOne nice property of the setup: a single grant handles both halves. The same connected account that reads calendar events also sends the reminder emails — no separate grants for calendar and email access.\n\nBecause the event object carries `title`\n\n, `location`\n\n, `conferencing.details.url`\n\n, `description`\n\n, and per-event timezones, the reminder can be a properly branded HTML email: meeting name, formatted local time, join link, agenda. The recipe formats times using the event's `start_timezone`\n\n— the docs are blunt that this is the hardest part to get right, and that an attendee in Tokyo doesn't want a time formatted for Chicago. Fall back to UTC when a provider leaves the timezone field empty.\n\nA reminder sent Tuesday is misinformation by Wednesday if the meeting moved. The recipe's second flow subscribes to `event.updated`\n\nand `event.deleted`\n\nwebhooks:\n\n```\ncurl --request POST \\\n  --url 'https://api.us.nylas.com/v3/webhooks/' \\\n  --header 'Authorization: Bearer <NYLAS_API_KEY>' \\\n  --header 'Content-Type: application/json' \\\n  --data '{\n    \"trigger_types\": [\"event.updated\", \"event.deleted\"],\n    \"description\": \"Event change notifications for reminder system\",\n    \"webhook_url\": \"https://your-server.com/webhooks/nylas\"\n  }'\n```\n\nThe handler's first move is a guard: if the event ID isn't in your sent-reminders store, do nothing. You only owe attendees an update about meetings you already told them about — otherwise every calendar edit in the account triggers email. For events that *do* match, `event.deleted`\n\n(or `status: \"cancelled\"`\n\n) gets a cancellation notice and removes the dedup entry; `event.updated`\n\ngets an \"Updated:\" email with the newly formatted time.\n\nBoth flows can share one process. Run the Express or Flask webhook server alongside the cron scanner — the cron handles proactive sends, the webhook listener handles reactive updates, and they read and write the same dedup store.\n\nOne sharp edge from the docs: the `event.deleted`\n\npayload is minimal — just the event ID, grant ID, and calendar ID. By the time you learn the meeting is gone, its title and participant list are gone too. Store event metadata alongside your reminder record at send time, or your cancellation email will read \"a meeting was cancelled\" with no way to say which one.\n\n`master_event_id`\n\n.Wire up just the fetch-and-filter half first: run the 24-hour scan on the 15-minute cron and log which events *would* get reminders. A day of logs tells you whether your filters are right before any attendee sees a duplicate or a misfire. Then turn on sending and add the webhook listener for changes. The [full recipe](https://developer.nylas.com/docs/cookbook/use-cases/act/schedule-event-reminders/) has Node.js and Python versions of every piece — which side of it would save your users more pain: the proactive reminder, or the cancellation notice that actually arrives?", "url": "https://wpnews.pro/news/event-reminders-from-an-agent-s-calendar", "canonical_source": "https://dev.to/qasim157/event-reminders-from-an-agents-calendar-5b6c", "published_at": "2026-06-13 11:21:55+00:00", "updated_at": "2026-06-13 11:47:35.204502+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Nylas", "Google Calendar", "Microsoft", "Exchange"], "alternates": {"html": "https://wpnews.pro/news/event-reminders-from-an-agent-s-calendar", "markdown": "https://wpnews.pro/news/event-reminders-from-an-agent-s-calendar.md", "text": "https://wpnews.pro/news/event-reminders-from-an-agent-s-calendar.txt", "jsonld": "https://wpnews.pro/news/event-reminders-from-an-agent-s-calendar.jsonld"}}