Changelog

What changed

• Every attachment download is audit-logged. A fetch of a file's downloadUrl records the time, IP address and user agent. A download from the dashboard also records the account, and an EmailConnect admin when one was acting as it. The entries appear under Logs, Activity (Platform plan) and are kept for your audit retention period, 90 days by default. The filename is not recorded.
• Inline attachments can be downloaded from the dashboard. The Files card in a message's delivery details now lists attachments that were delivered inside the payload, with a download button.
• Files are saved, not opened. A download from the dashboard or through a downloadUrl now saves the file under its original name instead of opening it in the browser.
• The logs API no longer returns attachment content. GET /api/v1/logs, GET /api/v1/emails/{id} and the dashboard's log list leave out each attachment's base64 content. Every other attachment field stays. Reading content there bypassed the audit log, and a single inline file could make a page of logs several megabytes. This took effect at once, without the usual notice period, because it closes an unaudited path to mail content.

A replay still sends the full payload, attachment content included. Stored files are fetched through their downloadUrl as before.

What changed

• Free accounts can sign webhooks. Set or generate a signing secret on a webhook in the dashboard, or pass generateSecret: true or webhookSecret through the API. Deliveries then carry the webhook-id, webhook-timestamp and webhook-signature headers. See webhook signing for verification code.
• The n8n EmailConnect Trigger can verify signatures on Free. Turn on Verify Signatures in the trigger and activate the workflow.
• A downgrade keeps signing secrets. Moving from a paid plan to Free used to clear them, which made a receiver that verifies signatures reject every delivery afterwards. Custom webhook headers are still removed on a downgrade.

Nothing changes for an existing webhook until you set a secret on it.

Who needs to act

Your endpoint needs a change if it reads any of these:

• storage, uploadType, excluded or excludeReason on an attachment entry, or the status values rejected and unknown
• base64 images inside message.content.html
• spam.report

The change applies to every webhook at the same moment. There is no per-webhook switch.

Telling the two shapes apart

From 9 November every payload carries "schemaVersion": 2 at the top level. A payload without it is the old shape. Messages stored before the change are replayed and retried in the old shape, without that field. Check for the field and you can handle both shapes, so you can deploy your change before the date.

1. Attachments: one status, one reason

Each entry in message.attachments loses storage, uploadType, excluded and excludeReason. Three fields take their place: status (always present), reason (when a file was left out or failed) and inline (always present).

Before

{
  "filename": "report.pdf",
  "contentType": "application/pdf",
  "size": 482113,
  "status": "completed",
  "storage": "s3",
  "uploadType": "sync",
  "downloadUrl": "https://…"
}

After

{
  "filename": "report.pdf",
  "contentType": "application/pdf",
  "size": 482113,
  "contentId": null,
  "inline": false,
  "status": "completed",
  "downloadUrl": "https://…"
}

status is one of:

status	Meaning
included	The file is in this payload, base64 in content.
completed	Stored. Fetch it from downloadUrl.
pending	Upload still running. downloadUrl answers 202 until it is done.
excluded	Left out by a rule or setting. reason says which.
failed	We could not process it. reason says why.

The payload is a snapshot taken at delivery: an entry that was pending stays pending in a replay.

A file that was left out:

Before

{
  "filename": "scan.tiff",
  "status": "rejected",
  "excluded": true,
  "excludeReason": "File size 3.20MB exceeds your attachment limit of 1MB. Adjust in Settings → Storage."
}

After

{
  "filename": "scan.tiff",
  "contentId": null,
  "inline": false,
  "status": "excluded",
  "reason": "too-large",
  "reasonDetail": "3.20 MB, limit 1 MB"
}

reason comes from a fixed list, so you can branch on it. reasonDetail is a short text for people and may change; do not parse it.

reason	With status
virus-detected	excluded
too-large	excluded
too-many-attachments	excluded
file-type-not-allowed	excluded
disabled-in-alias-settings	excluded
storage-not-available	excluded
content-unreadable	failed
storage-unreachable	failed
storage-rejected	failed
internal	failed

2. Images in the message body arrive once

Today an image pasted into a mail is written into message.content.html as base64 and also delivered as an attachment. From 9 November the HTML keeps the sender's cid: reference, and the image arrives once, as the attachment with the matching contentId and inline: true.

Before

{
  "content": {
    "html": "<p>See below</p><img src=\"data:image/png;base64,iVBORw0KGgo…\">"
  },
  "attachments": [
    { "filename": "image001.png", "status": "included", "storage": "inline", "content": "iVBORw0KGgo…" }
  ]
}

After

{
  "content": {
    "html": "<p>See below</p><img src=\"cid:image001.png@01DB2A\">"
  },
  "attachments": [
    { "filename": "image001.png", "contentId": "image001.png@01DB2A", "inline": true, "status": "included", "content": "iVBORw0KGgo…" }
  ]
}

inline is true when the HTML shows the file through a cid: reference, false for a file the sender attached. If you show message.content.html to people, replace each cid: reference with the attachment that has that contentId. With attachments switched off on an alias, images in the body no longer arrive at all.

3. spam.report is removed

The same information is in spam.symbols, already parsed. Free plans keep the { "available": false, "message": … } object in spam.

What does not change

Everything else: id, the webhook-id header, signatures, retries, message.sender, message.recipient, message.subject, message.content.text. We also add message.content.reply.markdown next to message.content.reply.text.

Payload templates and integrations

Custom payload templates keep working: no stored template names a removed field. A template that passes {{message.attachments}} or {{spam}} through whole delivers the new shape too.

Our n8n node needs no update for this change.

Questions about the change: write to support@emailconnect.eu.

What changed

The webhook payload's recipient object has a new field: tag.

Anything after a + in the recipient's address is a tag. Mail addressed to inbox+support@yourdomain.com is delivered to the webhook configured for your inbox@yourdomain.com alias — the tag doesn't need an alias of its own — and arrives like this:

"recipient": {
  "name": null,
  "email": "inbox+support@yourdomain.com",
  "tag": "support"
}

recipient.email keeps the full address the sender actually used, tag included. The tag field is that same value, pre-parsed for you.

Why

Splitting one intake channel into several used to mean creating an alias per stream — support-billing@, support-sales@, support-shipping@ — each wired to its own webhook, or a catch-all plus your own string-splitting on the address.

Now a single inbox@ alias backs an unlimited number of routing keys, and your endpoint switches on recipient.tag instead. Nothing to register, nothing to configure: any tag a sender invents reaches your endpoint.

Details worth knowing

• Untagged mail sets tag to null, never an empty string or a missing key. The field is always present, so you can rely on it.
• Only the first + separates. inbox+a+b@yourdomain.com gives you the tag a+b.
• A trailing + carries no tag. inbox+@yourdomain.com gives null — there's nothing after the delimiter.
• Tags are free-form and unauthenticated. You don't register them anywhere, which is the point, but it means a sender can put anything there. Treat tag as untrusted input: match it against values you expect rather than acting on it blindly.

What you need to do

Nothing. tag is additive — existing payloads gain a field and no existing field changes meaning. Start reading message.recipient.tag whenever it's useful to you.

See the webhook payload reference for the full field list.