Let your agent RSVP to invites it receives

An agent that gets invited to meetings should respond like a real attendee. Not with a polite "I'm an AI assistant, please contact my human" auto-reply. Not by silently dropping the invite on the floor. It should look at the meeting, look at its own calendar, and click Yes, No, or Maybe — the same three buttons every other person on the invite gets.

Most "AI calendar" demos run the other direction. They point a model at a human's Google Calendar and let it organize: propose times, send invites, chase RSVPs. That's the organizer flow, and it's useful. But the moment your agent has its own email address and people start inviting it to things, you need the mirror image. The agent is now an invitee, and invitees don't organize — they respond.

This post is about that response. An invite lands in the agent's mailbox, Nylas turns it into an event on the agent's calendar, your code decides yes/no/maybe based on whether the agent is actually free, and you fire a single send-rsvp call that updates the organizer's calendar the way any human's RSVP would. I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for, and I'll pair every one with the raw HTTP call so you can wire it into a backend with no SDK.

The grant is the whole data plane

Before the calendar mechanics, the one abstraction worth internalizing: an Agent Account is just a grant. It has a grant_id, and that grant_id addresses the same /v3/grants/{grant_id}/* endpoints every other Nylas grant does — Messages, Threads, Events, Calendars, free/busy, all of it. There's no special "agent API." If you've ever listed events or sent an RSVP for a connected Google or Microsoft account, you already know the surface area here. Nothing new to learn on the data plane.

What makes an Agent Account different is the identity: it owns a real mailbox and a real calendar on Nylas-hosted infrastructure, so it can be addressed, invited, and RSVP'd-against like a person. The endpoints are boring on purpose. The interesting part is that a piece of software is now a first-class participant on the invite.

If you're new to Agent Accounts, the are the two pages to read alongside this one.

How an inbound invite becomes an RSVP-able event

Here's the lifecycle, because it's the part people get wrong. The agent doesn't parse ICS attachments by hand, and it doesn't reply to the invite email to accept. Nylas does the ICS plumbing for you:

1. Someone in Google Calendar, Outlook, Apple Calendar — or another Agent Account — creates a meeting and adds the agent's address (say [email protected]) as a participant.


2. Their calendar sends the iCalendar invitation to the agent's mailbox. Nylas sees it, parses the meeting details, and creates a matching event on the agent's primary calendar. An event.created webhook fires.


3. On that event, the agent is listed in participants[] with status: "noreply". The organizer is whoever sent the invite — not the agent. The RSVP is pending.

That third point is the conceptual pivot. The agent is a participant, not the organizer. It can't update or cancel the meeting; it can only respond. And because the event object already carries the organizer, the participants, the time window, and the description, you can drive your whole decision off event.created without ever opening the invite email.

The agent also gets a message.created webhook for the invitation email itself, because an Agent Account is always a real mailbox too. You get to pick which signal drives your logic. My advice: drive the RSVP off event.created (it's already structured data) and treat the message.created as optional context you fetch only if you want the human-readable note the organizer wrote.

One honest caveat on the webhook body, because the Nylas docs hedge on it: don't rely on the webhook payload to hand you the full message body. Fetch the full message with GET /v3/grants/{grant_id}/messages/{message_id} when you need it, and branch on the message.created.truncated trigger name (it appears when a body exceeds ~1 MB and the body is omitted). For RSVP decisions you usually don't need the email at all — the event has everything.

Step 1: see the invite

You can react to event.created from a webhook, or you can poll. Webhooks are application-scoped — you subscribe once at the app level with POST /v3/webhooks, every grant's events land at your endpoint, and each payload carries a grant_id you filter on. That's the right call for near-real-time RSVPs. But for a tour, polling the events list is the clearest way to see the invite that just arrived.

List the agent's upcoming events with curl:

curl --request GET \

  --url "https://api.us.nylas.com/v3/grants/<GRANT_ID>/events?calendar_id=primary" \

  --header "Authorization: Bearer <NYLAS_API_KEY>" \

  --header "Accept: application/json"

And the CLI equivalent — same grant, same primary calendar:

nylas calendar events list --calendar primary

The invite shows up as an event where the agent's own address sits in participants[] with status: "noreply" and the organizer is someone else. That's your signal: this is an invitation the agent hasn't answered yet. Grab the id off that event — you'll need it to RSVP. Pull a single one for detail:

nylas calendar events show <event-id>

If you want the organizer's actual words — the "hey, can you join our planning sync?" note — fetch the invite email directly. The event.created and message.created webhooks both hand you a message id, so read that one message by id instead of listing the inbox:

# curl: fetch the invite message by id, body included

curl --request GET \

  --url "https://api.us.nylas.com/v3/grants/<GRANT_ID>/messages/<MESSAGE_ID>" \

  --header "Authorization: Bearer <NYLAS_API_KEY>" \

  --header "Accept: application/json"

# CLI: read the invite message by id

nylas email read <message-id>

If the invite came in on an existing thread, email threads show <thread-id> gives you the whole conversation so the agent has context before it commits to a time. None of this is required to RSVP — it's the layer you add when "should I accept?" depends on what the organizer wrote, not just on whether the slot is free.

Step 2: check whether the agent is actually free

This is the part that makes the RSVP mean something. Before the agent says yes, ask its calendar whether it's busy during the meeting window. Nylas exposes — the full organizer + invitee model, including hosting events the agent owns.

If you've already built the organizer side — the agent that sends invites and chases RSVPs — this is the missing half. Wire both and your agent isn't watching a calendar from the outside. It's on the invite.