Yesterday's send returned almost nothing useful — Gmail just confirms the send happened. Today's create returns something more interesting: the server-assigned ID of the new resource.
result = toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
"calendar_id": "primary",
"summary": "zuzu-day-10",
"start_datetime": "2026-12-31T10:00:00+00:00",
"event_duration_minutes": 30,
})
event_id = result.get("response_data", {}).get("id") or result.get("id")
print(event_id)The id is the calendar's identifier for the new event. You'd need it later to update or delete the event programmatically.
Why save the ID? Can't we just look it up by summary later?
Summary lookup works for unique names but breaks if you ever create two events with the same name. The ID is unique forever and never changes. Whenever a create-API gives you back an ID, save it — to a Sheet, a Notion page, a JSON file. State across runs is week 11 of Auto Intermediate; for now just be aware it's a real concern.
And the verification — does it look up the event in the calendar?
No, it just asserts the response had an id field. That's enough — Google's API only returns an ID when the create actually succeeded. Saves a quota slot vs a round-trip lookup.
Create APIs follow a consistent pattern: you pass the resource's data, and the response echoes back the server's representation — including the new ID.
result = toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
"calendar_id": "primary", # the user's main calendar
"summary": "zuzu-day-10", # event title
"start_datetime": "2026-12-31T10:00:00+00:00",
"event_duration_minutes": 30,
})
event_id = result.get("id")
print(event_id) # e.g. "abc123def456ghi789jkl"If you want to update or delete the event later, you need the ID:
toolset.execute_action(Action.GOOGLECALENDAR_UPDATE_EVENT, {
"calendar_id": "primary",
"event_id": event_id, # the ID from create
"summary": "zuzu-day-10 (updated)",
})Without the ID, you'd have to search by summary, which breaks on duplicates and is slower.
In a one-shot script, the ID lives in a local variable and disappears when the script ends. For automations that re-run on a schedule, you need persistence:
This is the foundation of idempotency and state across runs — both topics for Auto Intermediate. For week 2, just notice that the id exists and recognize it as the handle for any future operation on the resource.
assert result.get("id"), "event creation didn't return an id — did the API call succeed?"The API only returns an id field on a successful create. You don't need a second lookup to confirm — the ID's presence is the confirmation.
Yesterday's send returned almost nothing useful — Gmail just confirms the send happened. Today's create returns something more interesting: the server-assigned ID of the new resource.
result = toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
"calendar_id": "primary",
"summary": "zuzu-day-10",
"start_datetime": "2026-12-31T10:00:00+00:00",
"event_duration_minutes": 30,
})
event_id = result.get("response_data", {}).get("id") or result.get("id")
print(event_id)The id is the calendar's identifier for the new event. You'd need it later to update or delete the event programmatically.
Why save the ID? Can't we just look it up by summary later?
Summary lookup works for unique names but breaks if you ever create two events with the same name. The ID is unique forever and never changes. Whenever a create-API gives you back an ID, save it — to a Sheet, a Notion page, a JSON file. State across runs is week 11 of Auto Intermediate; for now just be aware it's a real concern.
And the verification — does it look up the event in the calendar?
No, it just asserts the response had an id field. That's enough — Google's API only returns an ID when the create actually succeeded. Saves a quota slot vs a round-trip lookup.
Create APIs follow a consistent pattern: you pass the resource's data, and the response echoes back the server's representation — including the new ID.
result = toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
"calendar_id": "primary", # the user's main calendar
"summary": "zuzu-day-10", # event title
"start_datetime": "2026-12-31T10:00:00+00:00",
"event_duration_minutes": 30,
})
event_id = result.get("id")
print(event_id) # e.g. "abc123def456ghi789jkl"If you want to update or delete the event later, you need the ID:
toolset.execute_action(Action.GOOGLECALENDAR_UPDATE_EVENT, {
"calendar_id": "primary",
"event_id": event_id, # the ID from create
"summary": "zuzu-day-10 (updated)",
})Without the ID, you'd have to search by summary, which breaks on duplicates and is slower.
In a one-shot script, the ID lives in a local variable and disappears when the script ends. For automations that re-run on a schedule, you need persistence:
This is the foundation of idempotency and state across runs — both topics for Auto Intermediate. For week 2, just notice that the id exists and recognize it as the handle for any future operation on the resource.
assert result.get("id"), "event creation didn't return an id — did the API call succeed?"The API only returns an id field on a successful create. You don't need a second lookup to confirm — the ID's presence is the confirmation.
Create a free account to get started. Paid plans unlock all tracks.