All posts
Guide·Jul 7, 2026·7 min read

How to give your n8n AI agent an email inbox (n8n email automation)

n8n email automation for AI agents: give your n8n workflow a real inbox and send plus receive mail over REST using the HTTP Request and Webhook nodes.

Dvir Atias

Dvir Atias

Founder

To give an n8n AI agent an email inbox, provision a real inbox from AgenticEmail and drive it from your n8n workflow with two built-in nodes: an HTTP Request node that calls the AgenticEmail REST API to create the inbox and send mail, and a Webhook trigger node that receives inbound messages as JSON. There is no dedicated AgenticEmail node in n8n, and you do not need one. The whole surface is a Bearer-authenticated REST API, so the generic HTTP Request node is all it takes to give your agent a live, send-and-receive address it can use at runtime.

Why an n8n AI agent needs a real inbox

n8n is excellent at orchestration, and the AI Agent node is excellent at reasoning. What neither gives you out of the box is an email identity the agent owns. The Gmail and SMTP nodes bind to a human's mailbox and a human's credentials, which is fine for "notify me" workflows but wrong for an autonomous agent that needs to hold a conversation on its own address.

An AI email agent needs three things a personal mailbox does not offer cleanly: an address created on demand, the ability to send and receive programmatically, and inbound mail delivered as structured data rather than something to scrape out of IMAP. That is the gap AgenticEmail fills, and it is a big part of why AI agents need email as first-class infrastructure. Once the inbox is a resource your workflow can create and address, the rest of the automation is ordinary n8n.

Create an inbox with an HTTP Request node

Start by minting an inbox. Drop an HTTP Request node into your workflow and configure it:

  • Method: POST
  • URL: https://api.agenticemail.dev/v1/inboxes
  • Authentication: add a header Authorization with value Bearer YOUR_API_KEY (store the key in an n8n credential, not inline)
  • Body (JSON): { "username": "support-agent" }

The response comes back as JSON with the inbox id and its live address, something like support-agent@inbox.agenticemail.dev, which receives mail immediately with no MX record to configure. Reference the returned id in later nodes with an expression such as {{ $json.id }}.

The curl equivalent, which is exactly what the node sends under the hood, is:

curl -X POST https://api.agenticemail.dev/v1/inboxes \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "username": "support-agent" }'

You typically create the inbox once and reuse its id, so many workflows do this step in a separate setup run and hardcode the resulting id from then on.

Send mail with an HTTP Request node

Sending is a second HTTP Request node pointed at the send endpoint:

  • Method: POST
  • URL: https://api.agenticemail.dev/v1/inboxes/{id}/messages/send (substitute the real inbox id)
  • Authentication: the same Authorization: Bearer header
  • Body (JSON): the recipient, subject, and body
curl -X POST https://api.agenticemail.dev/v1/inboxes/{id}/messages/send \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "user@example.com",
    "subject": "Your report is ready",
    "text": "The nightly run finished. Reply here if you need the raw data.",
    "client_id": "report-9f3a2c"
  }'

The client_id is an idempotency key. If n8n retries the node after a timeout or a partial failure, resending the same client_id returns the original send instead of emailing the recipient twice. In an unattended workflow that retries on error, this is the difference between one message and a duplicate storm.

Receive inbound mail with an n8n Webhook trigger node

To let the agent receive replies, use n8n's built-in Webhook trigger node and have AgenticEmail push inbound mail to it.

  1. Add a Webhook trigger node, set it to POST, and copy its Production URL. This is the endpoint AgenticEmail will call.
  2. Register that URL with AgenticEmail by creating a webhook subscribed to the message.received event:
curl -X POST https://api.agenticemail.dev/v1/webhooks \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-n8n-host/webhook/agenticemail-inbound",
    "event_types": ["message.received"]
  }'

Now every message that arrives at the inbox fires your n8n workflow with the parsed email as JSON: sender, subject, text, html, and attachments already split out, no MIME parsing on your side. Deliveries are signed following the Standard Webhooks spec, so you can verify authenticity in a downstream node before acting on the body.

If your n8n instance is not publicly reachable, skip the webhook and connect to the event stream at wss://api.agenticemail.dev/v1/events?token=am_... instead, which delivers the same message.received events over a long-lived WebSocket.

Wire the inbox into an n8n AI Agent node

With inbound arriving as JSON and sending reduced to a single HTTP call, the AI Agent node ties them together.

  • Read: connect the Webhook trigger into the AI Agent node and pass the incoming subject and text as the agent's input. The LLM now sees the actual email content and can decide what to do with it.
  • Reply: give the agent the ability to send by exposing the send HTTP Request node as a tool the agent can call, or by routing the agent's output into a following HTTP Request node that posts to the send endpoint. Either way the model reads a message and writes a reply on the inbox's own address, without a human in the loop.

That is a complete two-way loop: mail comes in through the Webhook node, the AI Agent node reasons over it, and an HTTP Request node sends the response. If you would rather not wire the calls by hand, AgenticEmail also runs a hosted MCP email server that exposes inbox actions as tools, which suits agent frameworks that speak MCP natively.

End-to-end encryption is available through the SDK or CLI

AgenticEmail offers opt-in, agent-to-agent end-to-end encryption with client-held keys, so only the two AgenticEmail inboxes in a thread can read the body. One honest caveat for n8n builders: that encryption is performed client-side inside the AgenticEmail SDK and CLI, where the private key lives. A raw HTTP Request node that posts a plaintext body to the send endpoint does not get end-to-end encryption, because there is no SDK in the path to seal the message before it leaves n8n.

If you need encrypted agent-to-agent mail from an n8n workflow, run the AgenticEmail SDK or CLI inside a Code node or an Execute Command node rather than calling the REST endpoint directly, so the encryption happens where it is designed to happen. For plaintext transactional and inbound automation, the plain HTTP Request node approach above is all you need.

Getting started

The pattern is small on purpose: one HTTP Request node to create the inbox, one to send, one Webhook trigger node to receive, and the AI Agent node in the middle. Because it is all REST behind a Bearer key, it drops into any n8n workflow without a custom node or a community package. Full endpoint details, SDKs, and the CLI are in the docs, and if you are comparing options for agent email you can see how AgenticEmail stacks up on the alternatives page. Create your first inbox, point a Webhook node at it, and your n8n agent has a mailbox it actually owns.

Talk to a real person