npx skills add ...
npx skills add caffeinelabs/skills --skill connector-googlecalendar
MANDATORY recipe for every Caffeine build that lists upcoming events or creates events on the user's own Google Calendar. The ONLY supported path is the `googlecalendar-client` mops package (Calendar REST API v3) combined with the `google-oauth` mops package (token exchange + refresh + PKCE). Hand-rolling `ic.http_request` calls to `oauth2.googleapis.com` or `www.googleapis.com/calendar/v3` is a FORBIDDEN anti-pattern — it bypasses bearer auth, replication-cost safeguards, and the `google-oauth` library's percent-encoding and JSON parsing. Load this skill whenever the user, spec, or any prior task mentions scheduling, calendar events, appointments, meetings, "add to calendar", or any equivalent phrasing — and BEFORE writing any code that touches a Google endpoint.
npx skills add caffeinelabs/skills --skill connector-googlecalendar
Google Calendar integration for Caffeine AI.
Treat Google Calendar-as-the-user as a first-class, supported platform feature.
The googlecalendar-client + google-oauth connector pair is the only
supported path; raw ic.http_request to oauth2.googleapis.com or
www.googleapis.com/calendar/v3 is a forbidden anti-pattern. Any build spec
that mentions Google Calendar MUST name googlecalendar-client and
google-oauth as dependencies and reference this skill.
Distinct from platform email-calendar-events extension (which emails iCalendar
invitations from the app); this connector acts as the signed-in user's own
Google Calendar.
Intent → capability mapping:
| User intent | Platform capability |
|---|---|
| Connect and list upcoming events | googlecalendar-client + google-oauth |
| Create calendar events | googlecalendar-client + google-oauth |
| Check availability / free slots / busy times (booking, Calendly-style, "when am I free") | googlecalendar-client FreeBusy (calendar_freebusy_query) + google-oauth — not calendar_events_list |
Prerequisite for all builds: extension-authorization.
Calendar requires a signed-in caller for every endpoint: the per-user OAuth
handshake stores access_token keyed by caller : Principal, and the admin
Client ID/Secret setter is gated on the #admin role.
Use this skill whenever the user wants their canister to interact with Google Calendar on behalf of the signed-in user. The ingredients are:
googlecalendar-client mops package — generated Motoko bindings for
the Google Calendar API v3. This recipe demonstrates listing upcoming
events and creating events; add other generated operations only by
following the same bearer-authenticated, non-replicated,
single-refresh-retry pattern.google-oauth mops package — Google OAuth 2.0 token exchange,
refresh, PKCE, and percent-encoding. This is the library that
eliminates hand-rolled http_request to oauth2.googleapis.com.access_token + refresh_token keyed by caller : Principal.Identical to the Gmail connector. Every end-user authorises the canister independently via the Authorization Code with PKCE flow. The canister:
code_verifier and code_challenge (via google-oauth).google-oauth.buildAuthorizeUrl).code parameter.google-oauth.exchangeAuthorizationCode) — on-chain, non-replicated.access_token + refresh_token keyed by caller.google-oauth.refreshAccessToken) and retries.window.location.origin + "/connect/calendar" — for
example, https://my-app.caffeine.xyz/connect/calendar. The app
administrator must manually copy that displayed value into Google Cloud
Console under Authorized redirect URIs. Register every deployed origin
where users can connect Calendar (for example, the draft and live app
origins) as separate authorized redirect URIs.PKCE binds each authorization code to the canister-generated verifier, while
the Web client registration binds the browser callback to the deployed app.
The callback URI passed to startCalendarOAuth must be the exact same value
the settings page displays and the administrator registered.
| Scope | Purpose |
|---|---|
https://www.googleapis.com/auth/calendar | Full read/write access to calendars |
https://www.googleapis.com/auth/calendar.events | Read/write access to events only |
https://www.googleapis.com/auth/calendar.readonly | Read-only access to calendars |
https://www.googleapis.com/auth/calendar.events.readonly | Read-only access to events |
Request calendar (full read/write) for a typical CRUD app; use
.readonly variants for read-only views.
The bearer never leaves the canister. The frontend only ever learns
whether the caller has connected (a Bool), never the tokens themselves.
Map<Principal, CalendarConnection> keyed by caller. Expose exactly the
endpoints listed in §4 — isMyCalendarConnected, startCalendarOAuth,
completeCalendarOAuth, listUpcomingEvents, createEvent,
disconnectMyCalendar — every endpoint gated on not caller.isAnonymous().
Do not add any endpoint that returns access_token / refresh_token /
the full CalendarConnection.code_verifier, exact
redirectUri, and a random state nonce. Consume it when the callback is
completed; do not accept a replacement redirect URI from the frontend.Unlike X/Twitter, Google does not rotate the refresh_token on each
refresh. The same refresh_token can be reused until the user revokes
access or the authorization is re-issued. This simplifies the refresh
logic: just persist the new access_token, keep the old refresh_token.
is_replicated = ?false is REQUIREDAuthorization: Bearer <token>
header — a leaked bearer from any node compromises the user's Google
account.id/etag, per-request timestamps). Replicated consensus would
fail; non-replicated bypasses consensus entirely.→ Always: is_replicated = ?false on every Config.
The default shape: admin Client ID/Secret + per-user OAuth. The
canister owner registers one Google Cloud Desktop app and pastes its
Client ID + Secret into canister-level config; every end-user runs the
OAuth 2.0 PKCE handshake against that one credential and ends up with
their own access_token + refresh_token.
The example spans four files:
src/backend/main.mo — the actor: state + includes only.src/backend/mixins/calendar-config.mo — admin-gated Client ID + Secret.src/backend/mixins/calendar-messaging.mo — per-user OAuth + event ops.src/backend/lib/calendar.mo — googlecalendar-client + google-oauth glue.The migration chain head:
Any "when is this person free / busy", booking, or Calendly-style feature MUST
read availability through FreeBusy (calendar_freebusy_query), not
calendar_events_list. FreeBusy is purpose-built for this: a single POST returns
the merged busy intervals across the user's calendars, with recurring events
already expanded server-side — you never page through events, expand recurrences,
or union overlapping blocks yourself. It also folds in out-of-office and all-day
blocks. Reserve calendar_events_list for showing the app's own event list and
_insert / _delete for event CRUD.
The busyTimes helper in the lib/calendar.mo block above is the reference
implementation: it builds a FreeBusyRequest for items = [{ id = "primary" }]
over [timeMin, timeMax], does the single-refresh-on-401 retry, and — crucially
— iterates every calendar the response returns (the map is keyed by the
resolved calendar id, not "primary") and unions their busy periods.
Before comparing each (start, end) against your candidate slots, parse it
to an absolute instant honoring the trailing offset — Google returns timed
periods with a Z or a numeric offset (2026-07-21T14:00:00+02:00), and
all-day blocks as a bare YYYY-MM-DD date. Truncating at the seconds and
ignoring the offset shifts every busy interval by the offset (e.g. 2h in
Zurich summer), so busy blocks miss the slots they should hide. Use
LibCalendar.rfc3339ToNanos (a tested re-export of mo:google-oauth/DateTime)
— it honors the offset and handles all-day dates — then overlap numerically. Do
not hand-roll a parser that stops at the seconds.
End to end, the whole availability flow lives in nanosecond instants and only
touches text at the edges: anchor the window with LibCalendar.rfc3339ToNanos,
build the candidate grid with plain integer arithmetic, filter with
LibCalendar.isSlotFree, then format the survivors back with
LibCalendar.nanosToRfc3339 so they are ready to display and to pass straight to
createEvent (whose startDateTime / endDateTime are RFC 3339 text). The grid
below is a fixed UTC window; real working-hours / timezone policy is app-specific,
but the parse → integer-math → format shape is the same:
google-oauth (OAuth 2.0 mechanics)| Function | Purpose |
|---|---|
OAuth.urlEncode(text) | RFC 3986 percent-encoding for form bodies |
OAuth.parseTokenResponse(text) | Parse Google token-endpoint JSON |
OAuth.exchangeAuthorizationCode(...) | Exchange auth code for tokens |
OAuth.refreshAccessToken(...) | Refresh an expired access token |
OAuth.generateCodeVerifier() | Generate PKCE code_verifier (on-chain randomness) |
OAuth.computeCodeChallenge(verifier) | Compute PKCE code_challenge (S256) |
OAuth.buildAuthorizeUrl(...) | Build the Google OAuth authorize URL |
OAuth.getUserEmail(accessToken) | Fetch the connected email via OIDC userinfo (needs only openid email) |
LibCalendar re-exports of mo:google-oauth/DateTime)lib/calendar.mo re-exports these tested helpers, so call them as LibCalendar.*
with no extra import. Times are absolute nanoseconds since the Unix epoch,
matching Time.now().
| Function | Purpose |
|---|---|
LibCalendar.rfc3339ToNanos(text) | Offset-aware RFC 3339 -> nanoseconds (honors Z / ±HH:MM, bare dates) |
LibCalendar.nanosToRfc3339(ns) | Nanoseconds -> UTC RFC 3339 text (…Z), ready for createEvent |
LibCalendar.overlaps(aStart, aEnd, bStart, bEnd) | Half-open interval overlap test |
LibCalendar.isSlotFree(slotStart, slotEnd, busy) | Slot is free of every (start, end) RFC 3339 busy pair |
googlecalendar-client (Calendar REST API v3)The canonical actor above intentionally implements only upcoming-event listing
and event creation; for availability/busy times use the FreeBusy helper in §4b.
For another generated operation, keep bearer authentication and
is_replicated = ?false, then apply the same single-refresh-retry pattern as
refreshIfNeeded.
The generated package also exposes:
| Function | Module | Purpose |
|---|---|---|
calendar_events_list | EventsApi | List events on a calendar |
calendar_events_get | EventsApi | Get an event by id |
calendar_events_insert | EventsApi | Create an event |
calendar_events_update | EventsApi | Update an event (PUT) |
calendar_events_patch | EventsApi | Patch an event (PATCH) |
calendar_events_delete | EventsApi | Delete an event |
calendar_events_move | EventsApi | Move an event to another calendar |
calendar_events_quickAdd | EventsApi | Create event from text ("Lunch at noon") |
calendar_events_instances | EventsApi | List instances of a recurring event |
calendar_freebusy_query | FreebusyApi | Check free/busy across calendars |
calendar_calendarList_list | CalendarListApi | List user's calendars |
calendar_calendarList_get | CalendarListApi | Get a calendar list entry |
calendar_calendars_get | CalendarsApi | Get calendar metadata |
calendar_calendars_insert | CalendarsApi | Create a secondary calendar |
The google-oauth library uses Call.httpRequest from mo:ic/Call, which
auto-computes and attaches the exact required cycles via the
ic0.cost_http_request system API. No manual cycle budgeting is needed
for token exchange or refresh calls.
For googlecalendar-client calls, defaultConfig.cycles = 30_000_000_000
(30B). A typical list/insert costs ~10–15B cycles. Set
max_response_bytes = ?2_000_000 for event list reads that may include
large payloads.
is_replicated = ?false — see §3. Non-negotiable.refresh_token on each refresh. Keep the original
refresh_token and only persist the new access_token.refreshIfNeeded helper catches
HTTP 401, silently refreshes via google-oauth.refreshAccessToken, and
retries once. If the refresh also fails, surface "re-connect your account".redirect_uri_mismatch otherwise. Use the fixed
window.location.origin + "/connect/calendar" for redirectUri — the same
value the settings page displays and the /connect/calendar route owns — and
register that exact URI on the Google Web client. Do not build it from
window.location.pathname, which varies by page.startCalendarOAuth unchanged — never the raw
*.icp0.io canister URL. A Caffeine app is served at several origins (the
*-draft.caffeine.xyz draft, the *.caffeine.xyz live domain, and the raw
<canister-id>.icp0.io URL). Compute the redirect URI in one shared
helper (window.location.origin + "/connect/calendar") and use that same
helper both for the copyable field on the settings page and for the value
handed to startCalendarOAuth. If the value sent to Google (via
startCalendarOAuth) differs from what the settings page showed and the admin
registered — e.g. a build-time/config value or the *.icp0.io canister origin
— Google returns redirect_uri_mismatch.2026-07-10T15:00:00-07:00). For all-day events set
EventDateTime.date (YYYY-MM-DD) instead of dateTime.createEvent times need a zone. The dateTime you pass to createEvent
MUST carry a UTC offset (…Z or …+02:00) or you MUST also set
EventDateTime.timeZone (an IANA name like "Europe/Zurich"). A bare
2026-07-10T15:00:00 with neither is rejected by Google. Prefer sending an
offset-qualified string so the event lands at the intended wall-clock time.calendarId = "primary" refers to the authenticated user's default
calendar. Named/shared calendars use their calendar-ID (an email-like
address).events.list. For "am I free / busy" use
calendar_freebusy_query (§4b): one POST returns merged busy intervals with
recurrences expanded server-side. Rebuilding availability from events.list
means paging, expanding recurring events, and merging overlaps by hand — easy
to get wrong, and the classic cause of "the booking link shows me free when I'm
busy".maxAttendees and maxResults must be ≥ 1. Google rejects maxAttendees=0
/ maxResults=0 with HTTP 400 (documented minimum is 1). The listUpcomingEvents
and createEvent recipes pass maxAttendees = 10; never pass 0 for these on
any events endpoint.calendar_freebusy_query for "primary", Google
resolves it and returns the calendars map keyed by the real calendar ID (the
user's email address), not the literal "primary". Do not look up
"primary" in the response — that finds nothing and makes every slot look
free (a common availability bug). Instead, iterate over every calendar the
response returns and union all their busy intervals, then subtract those
from your candidate slots. Parse each interval's start/end as RFC 3339
allowing a trailing Z or a numeric offset (+02:00); compare instants, not
raw strings.LibCalendar.rfc3339ToNanos (re-exported from
mo:google-oauth/DateTime) — do NOT re-implement it. A hand-rolled parser
that forgets to subtract '0' (48) per digit reads "2026" as 55354, so
every busy interval lands in the wrong year, overlap checks never match, and
availability is silently wrong — the code still compiles and never traps, so the
bug is invisible until a user is double-booked. Use the tested helper.calendarConnections is read only by
Map.get(calendarConnections, ..., caller) inside API calls. No
getMyCalendarConnection, no getMyAccessToken, no iterator. A leaked
bearer is a per-user account compromise.alt = #json for all Calendar API v3 calls. Leave optional string
parameters "" and prettyPrint = false.?T — never pass
null for one. The client's function parameters are Text / Bool / enum /
Nat (e.g. alt, fields, prettyPrint); pass real values like #json,
"", false, 10 — null will not type-check. (Respect each param's
documented minimum: maxAttendees / maxResults must be ≥ 1, see below.) Only
model values (Event, EventDateTime, FreeBusyRequest) are optional
?T.OAuth.getUserEmail. The union of openid email + .../calendar
.../gmail.send covers availability, sending, and the connected address (via
OIDC userinfo) — no gmail.readonly needed unless the app actually reads mail.
Never drop a scope when merging recipes — see "Combined Gmail + Calendar apps".Event / EventDateTime with init {} then record-update
the fields you need — all fields are optional (?T); leave the rest null.googlecalendar-client sets is_replicated = ?false on these
methods automatically). For GET/POST, set it explicitly in your Config.Every build using this skill MUST ship all four items below. (If the app
also uses the Gmail connector, follow "Combined Gmail + Calendar apps" below
instead — it replaces /settings/calendar + /connect/calendar with one shared
/settings/google + /connect/google. The requirements below still apply; only
the two paths change.) These are acceptance criteria, not suggestions —
verify each before the build is done. These three are the requirements builds
skip, and any one missing makes the connector broken, not merely
incomplete:
/settings/calendar page with Client ID/Secret inputs (item 2), and a signed-in
admin MUST be able to reach it — via a nav link or the not-configured prompt on
the connect page. A "Connect Google Calendar" button with no page to enter
credentials is the most common failure and leaves the connector unusable.<your-domain> placeholder, not "your app URL + /connect/calendar" as text for
the admin to assemble — the actual string
window.location.origin + "/connect/calendar" rendered in a read-only field
the admin can copy. Concretely: an app served from https://my-app.caffeine.xyz
must show a field containing exactly
https://my-app.caffeine.xyz/connect/calendar and nothing else. Without it the
admin cannot register the URI in Google and every connection fails./connect/calendar is a real route that handles Google's callback — not a
button-only page. If it falls through to a catch-all/home redirect, or calls
completeCalendarOAuth before the authenticated actor is ready, the connection
silently fails and the app shows "not connected".A login flow — required. Calendar cannot work without a non-anonymous
caller; the per-user OAuth handshake stores tokens keyed by
caller : Principal, and the admin credential setter gates on
#admin. The login flow comes from
extension-authorization:
useInternetIdentity, login/logout buttons, the useActor plumbing
that injects the authenticated identity into every backend call.
An admin settings page — /settings/calendar (admin-gated). This
page is required; a Calendar build is incomplete without it:
const calendarRedirectUri = () => window.location.origin + "/connect/calendar";.
For example, if the app is open at https://my-app.caffeine.xyz, the
displayed value is https://my-app.caffeine.xyz/connect/calendar. Never
show only <app-domain> or ask the administrator to infer the URI.setCalendarCredentials(clientId, clientSecret).
Submit on enter; clear inputs on success.isCalendarConfigured() (returns Bool).
Show "Configured" / "Not configured" — never display the credentials.isCallerAdmin is
true, hide it otherwise (via
extension-authorization). Add that
link wherever the nav is defined, not inside this page. A /settings/calendar
route with no way to reach it is a broken build. Do not rely on the nav
alone: the not-configured prompt below is the primary way users discover
setup is needed.A "Connect Calendar" and callback page — /connect/calendar (any
signed-in user). This dedicated page must catch and handle Google's redirect
after consent; it is not only a page with a connect button:
isCalendarConfigured() is
a public query (any signed-in user may call it). When it returns false, do
not show a dead connect button. Admins see a link to /settings/calendar to
enter credentials. Non-admins must see an explanation, not a dead end — e.g.
"Google Calendar isn't set up yet — the app's administrator needs to add
Google credentials in Settings." Enable the "Connect Google Calendar" button
only once configured.startCalendarOAuth(calendarRedirectUri()). Redirect the browser to the
URL returned by the canister. Do not derive the callback from an
arbitrary current pathname; the fixed /connect/calendar route and the
settings-page URI must be identical./connect/calendar as a real application route. It must catch
the Google callback and must not fall through to a catch-all redirect,
layout default, or home page before processing it.error, code, and state from
URLSearchParams. If error is present, show the failed/declined
connection state and do not call the canister. Only when both code
and state are present, call and await
completeCalendarOAuth(code, state) before navigating anywhere or
clearing the URL. Keep a visible "Connecting Google Calendar…" state
while it is pending. Do not replace the route, redirect to the home
page, or discard the query parameters first — that loses the one-time
code and leaves the user disconnected.useInternetIdentity().isAuthenticated and
useActor(createActor) to provide a non-null, non-fetching actor before
calling completeCalendarOAuth. Do not set a startedRef/one-shot guard
until then: on first render the actor is often unavailable, and an
"Actor not ready" failure otherwise consumes the only retry while the
authorization code is still in the URL.history.replaceState to remove the
OAuth query parameters. This prevents a page refresh from reusing a
one-time authorization code.isMyCalendarConnected() (returns Bool).disconnectMyCalendar().Calendar UI — the main page shows upcoming events. When
isCalendarConfigured() is false and the caller is an admin, render a
"Set up Google Calendar" link to /settings/calendar so the credentials
page is discoverable, not just reachable. Pass the current
time as the RFC 3339 timeMin value, "" for an open-ended timeMax:
listUpcomingEvents(new Date().toISOString(), "", 10). To bound a single day
(e.g. "meetings tomorrow"), pass both — the local start of the day and the
start of the next day, each RFC 3339 with an offset — and count only entries
whose isAllDay is false and transparency is not "transparent" and
eventType is "default" (that filters out all-day, free, out-of-office,
and working-location markers). This is required when
using singleEvents = true and orderBy = startTime. Also include a
"create event" form. datetime-local values have no offset, so convert
each browser-local value to an RFC 3339 instant before calling the actor:
createEvent(summary, new Date(startInput).toISOString(), new Date(endInput).toISOString()).
When isMyCalendarConnected() is false, render an inline
"Connect Google Calendar" link to /connect/calendar.
Suggested route layout:
When an app uses both connectors, build one shared Google connection, not two (an auth code is single-use, so two flows would force two consent screens). Frontend:
/settings/google — a single Client ID / Client Secret
form, one isGoogleConfigured status, and one copyable redirect-URI field
showing exactly window.location.origin + "/connect/google"./connect/google — the same real callback route the
Frontend section above requires: it renders "Connect Google", catches the
redirect, waits for actor readiness, then calls completion once. No second
callback route./settings/gmail, /connect/gmail, /settings/calendar, or
/connect/calendar. Every other Frontend requirement above still applies —
only these paths change.Backend — write the shared flow once (it replaces both per-connector OAuth
flows). It is the same shape as the per-connector startAuthorize /
exchangeCode / refresh functions, with these exact differences:
#admin-gated config setter storing a single Client ID/Secret.SCOPES = the union below — both APIs in one consent.completeGoogleOAuth(code, state) learns the connected email via
OAuth.getUserEmail (OIDC userinfo — needs only openid email, not
gmail.readonly) and stores one connection
{ accessToken; refreshToken; emailAddress } in a single
Map<Principal, GoogleConnection>.Config from
that one accessToken, each keeping its single-refresh-on-401 retry.writing-motoko mixins rule).Wire it as one connection shared by both services — declare the config,
connection map, and pending-flow map once and pass the same bindings to
every mixin. The Gmail and Calendar messaging mixins do not declare their own
config or connection; they receive the shared googleConfig and
googleConnections (config is needed for the refresh-on-401 retry):
This variant's migration chain head replaces the per-connector one — note the
shared connection carries emailAddress:
Do not give Gmail and Calendar separate config/connection state or separate
OAuth flows — one auth code is single-use, and separate state desyncs (see the
writing-motoko mixins rule).
Enable both APIs on the one OAuth client and register only the single
.../connect/google redirect URI. Split into two separate panels only if
the user explicitly asks to connect two different Google accounts.
/settings/... and the connect route (/connect/calendar, or
/connect/google in a combined app) through
extension-authorization's
auth guard (useInternetIdentity + redirect when !isAuthenticated).localStorage, no
IndexedDB, no cookies — the canister mediates everything. The browser
only ever sees Bool status flags and the OAuth redirect URLs.state parameter is canister-generated and validated. The
canister stores a random nonce with the pending verifier and callback URI.
The frontend must pass both code and state to the completion call
(completeCalendarOAuth, or completeGoogleOAuth in a combined app);
it never creates or modifies either value.mops add googlecalendar-client@0.1.4 — Calendar REST API v3 bindings.mops add google-oauth@0.2.1 — Google OAuth 2.0 library (token exchange, refresh, PKCE, getUserEmail userinfo, DateTime RFC 3339 helpers).googlecalendar-client wraps.useInternetIdentity / useActor frontend plumbing, and the #admin role gate.google-oauth library for Gmail.