{"slug": "give-your-ai-agent-its-own-inbox-nylas-agent-accounts-via-api-and-cli", "title": "Give your AI agent its own inbox: Nylas Agent Accounts via API and CLI", "summary": "Nylas launched Agent Accounts in June 2026, providing AI agents with their own email addresses and calendars that are indistinguishable from human-operated accounts. The accounts are provisioned via CLI or API and work with existing Nylas endpoints, allowing agents to send, receive, and RSVP to events. Developers can use a trial domain or register their own to build sender reputation.", "body_md": "Most \"AI email\" demos point a model at a human's inbox over OAuth. That's fine until you want the agent to *be* a participant — to have its own address that people reply to, that calendars invite, and that builds its own sender reputation. Pointing at someone's personal inbox doesn't give you that.\n\nNylas **Agent Accounts** take the other approach: a real `name@yourdomain.com`\n\nmailbox and calendar that the agent owns end to end. It sends, receives, hosts events, and RSVPs — and to anyone on the other side it's indistinguishable from a human-operated account. It went GA in June 2026.\n\nThe part I like as an SRE: it's not a new API surface. An Agent Account is just another Nylas [grant](https://developer.nylas.com/docs/v3/auth/). It gets a `grant_id`\n\nthat works with every endpoint you already use — Messages, Drafts, Threads, Folders, Attachments, Calendars, Events, Webhooks. Nothing new to learn on the data plane.\n\nThis walkthrough provisions one two ways (CLI and raw API), then sends, receives, RSVPs, and adds guardrails.\n\nWhen you create an Agent Account, Nylas provisions a real mailbox on a domain you've registered (or a Nylas `*.nylas.email`\n\ntrial domain). Each account comes with:\n\n`inbox`\n\n, `sent`\n\n, `drafts`\n\n, `trash`\n\n, `junk`\n\n, `archive`\n\n), plus any custom ones you create`grant_id`\n\nfor all the existing Nylas endpointsYou need two things:\n\n`nylas init`\n\ncreates an account and generates a key in one command.`*.nylas.email`\n\ntrial subdomain (good for testing in minutes) or your own custom domain with MX + TXT records. Register it under Organization Settings → Domains.Why your own domain? It's what makes the agent a real first-class sender instead of a shared relay address — people reply to it, calendars invite it, and its mail authenticates as coming from you. A new domain builds sender reputation over roughly four weeks of gradual sending, so run one domain per customer or use case to keep reputations isolated.\n\nAfter `nylas init`\n\n, provisioning is one command:\n\n```\nnylas agent account create test@your-application.nylas.email\n```\n\nThe CLI prints the new grant ID alongside connector and status details. A few companion commands:\n\n```\n# List every agent account\nnylas agent account list\n\n# Confirm the connector is ready\nnylas agent status\n\n# Show one account\nnylas agent account get test@your-application.nylas.email\n\n# See how accounts, workspaces, policies, rules, and lists fit together\nnylas agent overview\n```\n\nThat last one — `nylas agent overview`\n\n— renders a tree per account and flags dangling references to deleted policies/rules. It's the command I'd reach for first when something looks misconfigured.\n\nUnder the hood the CLI calls [ POST /v3/connect/custom](https://developer.nylas.com/docs/reference/api/manage-grants/byo_auth/) with\n\n`\"provider\": \"nylas\"`\n\n— the same Bring Your Own Auth endpoint used for other providers, minus the refresh token. Just the email on a registered domain:\n\n```\ncurl --request POST \\\n  --url \"https://api.us.nylas.com/v3/connect/custom\" \\\n  --header \"Authorization: Bearer <NYLAS_API_KEY>\" \\\n  --header \"Content-Type: application/json\" \\\n  --data '{\n    \"provider\": \"nylas\",\n    \"name\": \"Test Agent\",\n    \"settings\": {\n      \"email\": \"test@your-application.nylas.email\"\n    }\n  }'\n```\n\nThe response contains a `grant_id`\n\n— **save it**, you'll use it everywhere. The top-level `name`\n\nsets the display name recipients see on outbound mail (`Test Agent <test@your-application.nylas.email>`\n\n). Omit it and the account sends with no display name.\n\nTwo ways, same as any grant.\n\n**Poll the messages endpoint:**\n\n```\ncurl --request GET \\\n  --url \"https://api.us.nylas.com/v3/grants/<GRANT_ID>/messages?limit=5\" \\\n  --header \"Authorization: Bearer <NYLAS_API_KEY>\"\n```\n\n**Or subscribe to a webhook** so Nylas calls you the moment mail arrives. From the CLI:\n\n```\nnylas webhook create \\\n  --url https://yourapp.example.com/webhooks/nylas \\\n  --triggers message.created\n```\n\nInbound mail fires the standard `message.created`\n\nwebhook — identical in shape to `message.created`\n\nfor any other grant, so a handler you already have just works. On top of that, Agent Accounts emit deliverability webhooks like `message.delivered`\n\n, `message.bounced`\n\n, and `message.complaint`\n\nfor tracking outbound mail.\n\nSame `/messages/send`\n\nendpoint you'd use for a connected grant:\n\n```\ncurl --request POST \\\n  --url \"https://api.us.nylas.com/v3/grants/<GRANT_ID>/messages/send\" \\\n  --header \"Authorization: Bearer <NYLAS_API_KEY>\" \\\n  --header \"Content-Type: application/json\" \\\n  --data '{\n    \"subject\": \"Hello from my Agent Account\",\n    \"body\": \"This message was sent by a Nylas Agent Account.\",\n    \"to\": [{ \"email\": \"you@yourdomain.com\", \"name\": \"You\" }]\n  }'\n```\n\nThe recipient sees a normal message from the agent's address — no \"sent via\" branding, no relay footer.\n\nEvery Agent Account ships with a primary calendar, reachable through the same Events endpoints:\n\n`GET /v3/grants/{grant_id}/events`\n\n— list events`POST /v3/grants/{grant_id}/events`\n\n— create an event and invite others`POST /v3/grants/{grant_id}/events/{id}/send-rsvp`\n\n— accept or decline an invitationInvitations travel over standard iCalendar/ICS, so Google Calendar, Microsoft 365, and Apple Calendar all treat the agent as a normal participant. This is what lets a scheduling agent propose slots and have participants accept them as ordinary invites.\n\nProvisioning gives you a working mailbox. The interesting operational part is constraining what it can do. Three application-scoped resources handle that:\n\n`block`\n\n, `mark_as_spam`\n\n, `assign_to_folder`\n\n, `archive`\n\n, or `trash`\n\n.`in_list`\n\noperator.They attach through **workspaces**, not individual grants: a workspace carries one `policy_id`\n\nand an array of `rule_ids`\n\n, and every account in it inherits both. Each application has a default workspace, so configuring it governs all your unassigned accounts at once.\n\nInspect them from the CLI:\n\n```\nnylas agent policy list\nnylas agent rule list\nnylas agent list list\n```\n\nAnd create each piece from the CLI:\n\n```\n# A typed list of domains you can reference from a rule's in_list condition\nnylas agent list create --name \"Blocked domains\" --type domain --item spam.com\n\n# An outbound rule that archives the sent copy of mail to a recipient domain\nnylas agent rule create \\\n  --name \"Archive outbound mail\" \\\n  --trigger outbound \\\n  --condition recipient.domain,is,example.com \\\n  --action archive\n\n# A policy you can attach to a workspace\nnylas agent policy create --name \"Strict Policy\"\n```\n\nSwap `--action archive`\n\nfor `--action block`\n\nand the rule rejects the message instead — before it ever reaches the mailbox (inbound) or the provider (outbound). That's handy for data-loss prevention, keeping test domains out of production, or stopping an agent from emailing the wrong people. Inbound and outbound rules are isolated: inbound rules never run on sends, and outbound rules never re-evaluate the stored sent copy.\n\nPolicies are optional. Skip them and the account runs at your billing plan's maximum limits and delivers every inbound message to the inbox.\n\n| Dimension | Default | Notes |\n|---|---|---|\n| Send rate | 200 messages/account/day | Paid plans have no daily cap by default |\n| Storage | 3 GB/org | Higher on paid plans |\n| Retention | 30 days inbox, 7 days spam | Configurable via policy |\n| Domains | Unlimited | One application can manage accounts across any number of domains |\n\nThe thing that makes Agent Accounts click is that there's no second system. You provision an identity with one CLI command or one API call, and from that point it's the same Messages, Events, and Webhooks surface you'd use for a connected Gmail or Microsoft grant — now owned by your agent instead of borrowed from a user.\n\nIf you want to go deeper:\n\n*Written by Qasim Muhammad and Pouya Sanooei.*", "url": "https://wpnews.pro/news/give-your-ai-agent-its-own-inbox-nylas-agent-accounts-via-api-and-cli", "canonical_source": "https://dev.to/mqasimca/give-your-ai-agent-its-own-inbox-nylas-agent-accounts-via-api-and-cli-1c5o", "published_at": "2026-06-21 18:41:28+00:00", "updated_at": "2026-06-21 19:03:49.130637+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Nylas", "Agent Accounts", "Nylas API", "Nylas CLI"], "alternates": {"html": "https://wpnews.pro/news/give-your-ai-agent-its-own-inbox-nylas-agent-accounts-via-api-and-cli", "markdown": "https://wpnews.pro/news/give-your-ai-agent-its-own-inbox-nylas-agent-accounts-via-api-and-cli.md", "text": "https://wpnews.pro/news/give-your-ai-agent-its-own-inbox-nylas-agent-accounts-via-api-and-cli.txt", "jsonld": "https://wpnews.pro/news/give-your-ai-agent-its-own-inbox-nylas-agent-accounts-via-api-and-cli.jsonld"}}