The grant_id: One Handle for Mail, Calendar, and Webhooks

Anyone who's wired an autonomous agent into email and calendar the traditional way knows the identifier sprawl: an OAuth client ID, a refresh token per user, a Gmail-specific message ID format, a Microsoft Graph calendar ID, and a webhook subscription ID for each — all with different lifetimes, all able to break independently. Half your "integration" code is really identifier bookkeeping.

Nylas Agent Accounts collapse all of that into one value. When you create an account (the feature's in beta), the response hands you a grant_id, and that single string is the handle for everything the agent does — mail, calendar, contacts, attachments, and the webhooks reporting on all of them.

One ID, the whole surface

Every operation addresses the same path family, /v3/grants/{grant_id}/*:

POST   /v3/grants/{grant_id}/messages/send         # send mail
GET    /v3/grants/{grant_id}/messages              # read the inbox
GET    /v3/grants/{grant_id}/threads/{thread_id}   # full conversation
GET    /v3/grants/{grant_id}/attachments/{id}/download
POST   /v3/grants/{grant_id}/events                # host a meeting
POST   /v3/grants/{grant_id}/events/{id}/send-rsvp # respond to one
GET    /v3/grants/{grant_id}/contacts
GET    /v3/grants/{grant_id}/rule-evaluations      # audit trail

This isn't an abstraction invented for agents — an Agent Account is literally just another grant, the same primitive used for connected Gmail and Outlook accounts. The supported endpoints reference puts it as "same endpoints, same auth, same payloads." Anything you built for connected accounts works against an agent's grant unchanged.

And the resources behind the ID are real: six system folders provisioned automatically (inbox, sent, drafts, trash, junk, archive), a primary calendar that speaks standard iCalendar, and outbound messages capped at 40 MB total.

Webhooks route by it too

The inbound side completes the picture. You subscribe once at the application level, and every notification — message.created, event.updated, message.bounce_detected, and the rest — carries the grant_id of the account it happened to:

{
  "type": "message.created",
  "data": {
    "object": {
      "object": "message",
      "id": "<MESSAGE_ID>",
      "grant_id": "<NYLAS_GRANT_ID>",
      "subject": "Hello from Nylas",
      "from": [{ "email": "sender@example.com", "name": "Sender" }],
      "snippet": "This is a sample message"
    }
  }
}

So the dispatch logic in your webhook handler is one lookup: grant_id → which agent → which handler. One detail to plan for: when a message body exceeds ~1 MB, the trigger arrives as message.created.truncated with the body omitted — you fetch the full message through, naturally, the same grant_id.

The lifecycle is symmetric

The handle appears at birth and disappears at death, with nothing extra to manage in between. Creation is a single call — POST /v3/connect/custom with "provider": "nylas" — and the response's data.id is the grant_id:

{
  "request_id": "5967ca40-a2d8-4ee0-a0e0-6f18ace39a90",
  "data": {
    "id": "b1c2d3e4-5678-4abc-9def-0123456789ab",
    "provider": "nylas",
    "grant_status": "valid",
    "email": "sales-agent@agents.yourcompany.com",
    "scope": [],
    "created_at": 1742932766
  }
}

No refresh token in that payload, because there's no OAuth provider behind the grant. Reconfiguration is also one call against the same ID — PATCH /v3/grants/{grant_id} with a new workspace_id moves the account under a different policy and rule set. And teardown is deleting the grant, which emits grant.deleted through the same webhook subscription that reported its mail. Provision, operate, govern, destroy: four phases, one identifier.

Designing the data model

Since one ID anchors everything, the schema almost writes itself. The agents table needs surprisingly few columns:

CREATE TABLE agents (
  id            UUID PRIMARY KEY,
  grant_id      TEXT NOT NULL UNIQUE,  -- the Nylas handle
  email         TEXT NOT NULL,
  workspace_id  TEXT,                  -- policy/rule inheritance
  purpose       TEXT,                  -- 'support', 'outreach', ...
  created_at    TIMESTAMPTZ
);

A few practices that fall out of the docs:

Store the provider field alongside the grant. If your application handles both connected grants and agent grants, the agent ones report provider: "nylas" — that's the documented way to branch between "a human's mailbox we're acting on" and "a mailbox we own."
Don't cache derived state you can fetch. Folder IDs, calendar IDs, and thread membership all hang off the grant; refetch rather than mirror.
Key your queues and logs by grant_id. Per-agent send counters, per-agent webhook queues, per-agent audit views — they all need exactly one partition key, and this is it.
Treat the grant lifecycle webhooks as your CDC feed. grant.created, grant.updated, grant.deleted, and grant.expired tell you about fleet changes. The docs note agent grants rarely expire, because there's no OAuth token behind them to refresh — one whole failure class gone.

What doesn't hang off it

Worth knowing where the boundary sits. Policies, rules, and lists — the guardrail resources — are application-scoped, with no grant ID in the path. They reach the agent indirectly: a workspace carries a policy_id and rule_ids, the grant carries a workspace_id, and inheritance does the rest. So the grant is the handle for everything the agent does, while workspaces govern what it's allowed to do. The exception that proves the rule: GET /v3/grants/{grant_id}/rule-evaluations brings the audit trail back under the grant, answering "which rules ran on this account's mail?"

The plan limits split along the same lines, and it's useful to know which scope each one attaches to. The send quota — 200 messages per account per day on the free plan, no daily cap by default on paid plans — is per account. Storage (3 GB on the free plan) is per organization, shared across every agent. Retention (30 days inbox, 7 days spam on the free plan) comes through the workspace's policy. Three limits, three different scopes, and only one of them keyed by the grant — which is exactly the kind of thing your data model should encode rather than discover in production.

One more thing that hangs off the grant rather than the application: protocol access. Set an app_password on the grant and the same mailbox opens in Outlook, Apple Mail, or Thunderbird over IMAP and SMTP — useful when a human needs to supervise what the agent has been doing, and another case where the grant is the unit that carries the capability.

The single-handle design sounds like a small ergonomic win, but it compounds. Provisioning returns one value to persist; teardown deletes one grant; debugging starts from one ID that appears in every request path and every webhook payload.

Try this as a next step: take whatever per-user integration table you have today, count the identifier columns, and see how many survive a port to this model. If the answer is "one plus a workspace reference," your migration is mostly a column-drop. The overview is the right place to start reading.

推荐订阅源