GDPR retention and erasure for an agent mailbox
Most "AI email" demos never think about deletion. The agent reads, replies, files things away, and the inbox just grows. That's fine in a demo. It is a problem the first time a real person emails your agent, because the moment that mailbox holds someone else's name, address, order history, or support complaint, you've taken on a data-protection obligation — and "we kept everything forever" is not a defensible retention policy. An Agent Account on Nylas accumulates personal data you have to be able to purge. It's a mailbox the agent owns — support@yourcompany.com answering to a model instead of a human — and every inbound message lands in it. Under GDPR that data needs two things you can prove: a retention window so it doesn't live forever, and an erasure path so you can delete a specific person's mail when they ask. This post builds both, with the curl and the CLI for each step. A quick, honest caveat before any of it: this is a docs-and-demo walkthrough, not legal advice. The Nylas primitives below cover the mail held in the mailbox . Any derived copy you made — rows in your own database, lines in your application logs, a vector store you embedded the message into — is yours to purge separately. The API can delete the message; it can't reach into your Postgres. Keep that in mind throughout. What the platform gives you Nothing new to learn on the data plane. An Agent Account is just a grant with a grant_id , so everything you already know about Messages and Threads applies directly — listing, reading, and deleting mail run against the same grant-scoped endpoints any other Nylas integration uses. Retention and erasure split cleanly into two layers: Retention is a control-plane setting. It lives on a policy — an application-scoped resource that bundles limits and spam settings — attached to the workspace your Agent Account belongs to. Two fields cap how long mail survives: limit_inbox_retention_period and limit_spam_retention_period . Set them once and Nylas deletes a