Agent Accounts Quickstart in Python

Nylas released Agent Accounts in beta, offering a simplified provisioning flow for hosted mailboxes that requires only a single POST request instead of the traditional OAuth consent screen and refresh token management. A Python quickstart demonstrates creating an agent account, polling or receiving webhooks for messages, and handling attachments, making the service suitable for automation and test harnesses.

A connected Gmail grant starts with an OAuth consent screen and ends with a refresh token you have to babysit; a Nylas Agent Account starts and ends with one POST request. Same API surface afterward — same messages endpoints, same webhooks, same calendar — but the provisioning story couldn't be more different, and that difference is what makes these hosted mailboxes such a natural fit for Python automation, agents, and test harnesses. Agent Accounts are in beta, and the official quickstart https://developer.nylas.com/docs/v3/getting-started/agent-accounts/ gets you from nothing to a sending-and-receiving mailbox in under 5 minutes using curl. Here's the whole flow as a Python script. You need an API key run nylas init with the CLI, or use the Dashboard and a domain. The fast path for testing: register a .nylas.email trial subdomain from the Dashboard — no DNS records, instantly usable. Custom domains need MX and TXT records published at your DNS provider, with automatic verification once they propagate; save that for production. python import os import requests BASE = "https://api.us.nylas.com" HEADERS = { "Authorization": f"Bearer {os.environ 'NYLAS API KEY' }", "Content-Type": "application/json", } POST /v3/connect/custom with "provider": "nylas" . No refresh token — just an email address on a registered domain: resp = requests.post f"{BASE}/v3/connect/custom", headers=HEADERS, json={ "provider": "nylas", "settings": {"email": "test@your-application.nylas.email"}, }, resp.raise for status grant id = resp.json "data" "id" print f"Agent Account live: {grant id}" Save that grant id — per the docs, you'll use it in every subsequent call. The mailbox works with every existing endpoint from this moment on. If you want policies or mail rules applied, add a top-level workspace id to the same request body; the account inherits the workspace's limits, spam settings, and rules. Omit it and the account lands in your application's default workspace. Worth knowing there are two other creation paths to the same grant: nylas agent account create test@your-application.nylas.email from the CLI it prints the grant ID, and nylas agent account list shows the fleet , or Agent Accounts → Accounts → Create account in the Dashboard. The POST above is the path you'll automate, which is why this script uses it. Polling first, because it needs no infrastructure. List the inbox with the standard messages endpoint: inbox = requests.get f"{BASE}/v3/grants/{grant id}/messages", headers=HEADERS, params={"limit": 5}, .json for msg in inbox "data" : print msg "subject" , "-", msg "snippet" Fetching one message with its full body is the same route plus the message ID: GET /v3/grants/{grant id}/messages/{message id} . For push instead of poll, register a message.created webhook: requests.post f"{BASE}/v3/webhooks", headers=HEADERS, json={ "trigger types": "message.created" , "callback url": "https://yourapp.example.com/webhooks/nylas", }, And handle deliveries with a few lines of Flask: python from flask import Flask, request app = Flask name @app.post "/webhooks/nylas" def nylas webhook : payload = request.get json if payload.get "type" == "message.created": msg = payload "data" "object" print f"New mail on {msg 'grant id' }: {msg 'subject' }" return "", 200 The payload is identical in shape to message.created for a connected grant — the docs' example carries subject , from , to , date , and snippet under data.object . If your app mixes account types, the documented discriminator is the grant's provider field, which reports "nylas" for agent grants. Inbound attachments come through as IDs on the message; download the bytes from the attachments endpoint, passing the message ID as a query parameter: attachment = requests.get f"{BASE}/v3/grants/{grant id}/attachments/{attachment id}/download", headers=HEADERS, params={"message id": message id}, with open "invoice.pdf", "wb" as f: f.write attachment.content Size and count limits on inbound attachments are governed by your plan and the grant's policy — the knobs are limit attachment size limit , limit attachment count limit , and limit attachment allowed types on the policy object. Outbound is the same /messages/send endpoint used for any connected grant: requests.post f"{BASE}/v3/grants/{grant id}/messages/send", headers=HEADERS, json={ "subject": "Hello from my Agent Account", "body": "This message was sent by a Nylas Agent Account.", "to": {"email": "you@yourdomain.com", "name": "You"} , }, What the recipient sees is a normal email from the agent's address — no "sent via" branding, no relay footer. The docs' end-to-end test, scripted: send a message from your personal account to the agent's address, confirm it shows up webhook or the polling snippet , then fire the send call and watch the reply land back in your own inbox. Once that round trip works, you have a mailbox your Python code fully owns. Every account ships with a primary calendar, driven by the same grant id . Hosting a meeting is one more requests.post — with notify participants=true , each participant gets a real invitation from the agent's address: requests.post f"{BASE}/v3/grants/{grant id}/events", headers=HEADERS, params={"calendar id": "primary", "notify participants": "true"}, json={ "title": "Product demo", "when": {"start time": 1744387200, "end time": 1744390800}, "participants": {"email": "alice@example.com"} , }, And when someone invites the agent, it responds through send-rsvp with yes , no , or maybe : requests.post f"{BASE}/v3/grants/{grant id}/events/{event id}/send-rsvp", headers=HEADERS, params={"calendar id": "primary"}, json={"status": "yes"}, Everything travels over standard iCalendar, so Google Calendar, Microsoft 365, and Apple Calendar treat the agent as a normal participant — its RSVP is visible to every attendee. workspace id explicitly is the difference between an agent with guardrails and one running at plan maximums. .nylas.email addresses work instantly, but production agents belong on your own domain — ideally a dedicated subdomain like agents.yourcompany.com so agent traffic carries its own sender reputation. provider , not on the grant ID. provider field — agent grants report "nylas" . Hard-coding grant IDs into your dispatch logic falls apart the moment you provision account number two.The obvious next move is dropping an LLM into the webhook handler: classify the message, draft a reply, call send. If you build that — or hit any rough edge while trying — what's the first job you'd hand a mailbox that no human has to log into?