n8n email webhook triggers: how to give each agent its own inbox

You built an n8n workflow that processes incoming emails. It worked fine during testing. Then you deployed it, and Gmail's trigger node started polling every two minutes instead of firing instantly. OAuth tokens expired over the weekend. And when you tried to give a second workflow its own email address, you realized Gmail doesn't work that way.

Most n8n email automation guides start with the Gmail Trigger node because it's the path of least resistance. Connect your Google account, pick a label, done. But the Gmail Trigger has real limitations that surface the moment you need reliability, speed, or isolation between workflows.

There's a better pattern: give each workflow (or each agent) its own dedicated email address that POSTs incoming messages directly to an n8n webhook. No OAuth. No polling. No shared inbox. No midnight token refreshes.

How to trigger an n8n workflow from email#

An email trigger starts an n8n workflow automatically when a message arrives at a specified address or endpoint. Here are the main approaches:

1. Add a Gmail Trigger node as the workflow start and connect your Gmail OAuth2 credentials to poll for new messages.
2. Use a Webhook node to receive HTTP POST requests from an external service that forwards inbound emails as JSON payloads.
3. Configure an IMAP Email Trigger node to poll any IMAP-compatible mailbox at a set interval.
4. Set up a dedicated inbound email address (sometimes called a mailhook) that converts incoming emails into webhook POSTs to your n8n instance.
5. Test by sending a real email and verifying the workflow fires in the n8n execution log.

Each approach has different tradeoffs around latency, reliability, and the number of unique addresses you can create. The rest of this article breaks down when to use which.

Gmail trigger vs webhook trigger#

The Gmail Trigger node and the Webhook node solve the same problem (start a workflow when something happens) but they work in fundamentally different ways.

The Gmail Trigger polls your inbox on an interval. Every one to two minutes, it checks for new messages matching your filter criteria. When it finds one, the workflow runs. The upside: zero external setup. The downside: it's not real-time, it requires OAuth credentials that expire, and every workflow shares the same Gmail inbox.

The Webhook node listens for incoming HTTP POST requests at a unique URL that n8n generates. When a POST hits that URL, the workflow runs immediately. No OAuth, and each webhook gets its own URL. The catch: something else needs to send that POST. The Webhook node doesn't know about email on its own.

This is where the two approaches split. Gmail Trigger is self-contained but slow and fragile. Webhook is fast and reliable but needs an email-to-webhook bridge.

For a side project that handles 10 emails a day, Gmail Trigger is fine. For an agent that needs to process inbound email reliably, around the clock, with per-workflow routing, the webhook approach wins. We covered the webhooks vs polling tradeoff in more detail if you want a deeper comparison.

Where Gmail triggers break down#

Three failure modes show up repeatedly in production n8n deployments.

The most common is OAuth token expiry. Google's refresh tokens can be revoked by security policy changes, password resets, or extended inactivity. When the token dies, your workflow silently stops processing email. n8n doesn't alert you when this happens. You find out when a client says your agent stopped replying two days ago.

Then there's polling lag. The Gmail Trigger checks for messages every one to two minutes. If n8n restarts or deploys during a poll window, emails that arrived during the gap get missed entirely. Unlike webhook delivery (which queues and retries), polling has no memory of what happened while the instance was offline.

The third problem is the inbox itself. You can't create a new Gmail address per workflow without creating a new Google account per workflow. If you're building a multi-tenant application where each user or agent instance needs its own inbox, Gmail becomes unmanageable fast. The n8n community has been requesting built-in mailhook support for exactly this reason.

The mailhook pattern: one inbox per workflow#

A mailhook is a unique email address that converts incoming messages into HTTP webhooks. Send an email to workflow-123@yourdomain.com, and your n8n webhook URL receives a POST with the sender, subject, body, and attachments as structured JSON.

This solves all three Gmail problems at once. No OAuth tokens to manage, because the email service authenticates via webhook signatures (HMAC) instead of expiring user tokens. Delivery is real-time, with built-in retry logic so messages aren't lost during restarts or deployments. And each n8n workflow gets its own address. Route support emails to one workflow, invoices to another, agent replies to a third. No label-based filtering gymnastics.

Make.com has supported this pattern natively for years (they call it "custom mailhooks"). n8n doesn't have it built in yet, but you can wire it up with any external email service that supports inbound webhook forwarding.

Setting this up with LobsterMail and n8n#

LobsterMail is built for this pattern. Your agent hatches its own inbox via API, registers a webhook URL, and starts receiving email as structured JSON at that endpoint. Here's the setup:

// 1. Agent creates its own inbox
const inbox = await lm.createInbox({
  prefix: "support-workflow",
  ttl: "30d"
});
// → support-workflow-abc123@lobstermail.ai

// 2. Agent registers the n8n webhook as delivery target
await lm.createWebhook({
  url: "https://your-n8n.example.com/webhook/email-intake",
  events: ["email.received"],
});

On the n8n side, your workflow starts with a standard Webhook node pointed at /webhook/email-intake. When an email arrives at the inbox, LobsterMail POSTs the message data (sender, subject, body, attachments, thread ID) to your webhook URL. Your workflow processes it from there: through AI nodes, classification logic, database writes, whatever you need.

No Google OAuth. No polling interval. Each workflow instance gets its own email address, created programmatically. And if you want to test this without touching production, the free tier gives you sandbox inboxes that behave identically to live ones.

For n8n deployments where email is a core trigger (customer support agents, invoice processors, scheduling assistants), this approach removes the most common points of failure. Your agent provisions its own email, receives messages in real time, and you never have to re-authorize a Google account at 3am. If you want to try this pattern, get your agent its own inbox here. The free tier covers 1,000 emails per month, enough to validate the workflow before you need to scale anything.