Processing email attachments with AI in n8n: extraction, classification, and automatic archiving

A contact@ or applications@ inbox doesn't just receive text: it receives supplier invoices, résumés, scanned ID documents, PDF quotes, sometimes a spreadsheet or a screenshot. An n8n workflow that only reads the subject and body of an email misses most of the useful content. Handling an attachment properly requires one more step than handling plain text: fetch the binary, verify it's safe, extract its content based on format, then classify and file it in the right place. This guide covers that complete pipeline, designed to plug into an existing email-sorting workflow rather than replace it.

Why an attachment deserves separate handling

An email's body is text a LLM can use immediately. An attachment, by contrast, arrives as a binary: n8n first needs to know it exists, which binary property name it's stored under, what format it's in, and whether it's worth opening at all. That last question isn't a minor detail: a publicly exposed address (applications, contact, support) will inevitably, sooner or later, receive a malicious attachment disguised as a résumé or an invoice. A study by Muralidharan and Nissim published in Neural Networks (2023) on deep-learning detection of malicious email attachments shows that analyzing the header, body, and attachment as three distinct signals meaningfully improves detection compared to analyzing text alone — confirmation that the attachment isn't a side detail of the email, but a surface of its own that deserves its own filtering before processing.

Fetching attachments in n8n

The starting point is an email trigger: Email Trigger (IMAP) for a generic mailbox, or the native Gmail trigger if your mail runs on Google. Both expose attachments as binary properties on the item, but with different naming conventions:

• Gmail names each attachment attachment_0, attachment_1, and so on — you need to iterate over these properties rather than target a single one by name.
• Email Trigger (IMAP) generally groups attachments under property names tied to the file itself; check the node's output in debug mode before wiring the rest, conventions vary by source mail server.

In both cases, a Code node at the start of the pipeline that loops over $binary and normalizes each attachment into a separate item (with the file name, MIME type, and size as metadata) simplifies everything downstream: the rest of the workflow then handles "one document" without worrying about how many there were in the original email. If your attachments exceed a few dozen megabytes (high-resolution scans, large exports), our guide to large files in n8n covers the real memory limits and settings to know to avoid a crash.

Building the processing pipeline

1. Filter before opening anything

Before any call to a model, a simple IF or Switch node already removes most of the noise and risk: reject executable extensions (.exe, .js, .bat), unexpected archives (.zip, .rar) on an address that should only receive documents, and cap the accepted size. On a publicly exposed inbox, calling a file-scanning service (the VirusTotal API, for example) before any processing adds a cheap extra layer of protection — a simple HTTP Request node with the hash or the file as input.

2. Extract the content based on format

Once the file is deemed safe, extraction follows the same logic as for a standalone document — we cover this in depth in our guide to extracting data from PDF invoices:

• CSV, XLS/XLSX, HTML, plain text, PDF with native text → the Extract from File node is enough, with no API cost.
• Image, scan, PDF with no selectable text → a multimodal Chat Model (GPT-4o, Claude, Gemini) receives the base64-encoded binary and extracts the content directly, with no separate OCR step.

3. Classify the document automatically

The extracted content then flows into a Basic LLM Chain paired with a Structured Output Parser, with a schema that forces a category from a closed list (invoice, contract, resume, id_document, other) rather than free text. Classifying a document from its visual and textual content is a well-studied problem: Harley, Ufkes, and Derpanis showed as early as 2015, in their evaluation of convolutional networks for document image classification (ICDAR 2015), that a document's visual structure (layout, text density, presence of tables) alone carries a reliable classification signal — exactly what a modern multimodal LLM exploits in a single call, where the original paper required a dedicated trained model. Our guide to automatically classifying incoming documents covers this mechanism for a watched Drive or Dropbox folder; the principle here is identical, only the source (email rather than a watched folder) changes.

4. Route and name by category

A Switch node wired to the category field of the structured output routes each document to the appropriate downstream step: an invoice heads to the accounting-field extraction pipeline, a résumé to an applicant-tracking table, an ID document to encrypted storage with restricted access. Renaming the file to a consistent template at this stage ({date}_{category}_{sender}.pdf) avoids the pile-up of files named scan001.pdf that nobody can identify six months later.

Archiving, logging, and notifying

A classified document needs to end up somewhere traceable. For durable storage outside the mailbox, our guide to archiving files with S3 covers the S3 node (available in the Community Edition) and its Google Drive or Dropbox equivalent for a team already set up on those tools. In parallel, a row in a Supabase table (file name, category, sender, date, link to the archive) provides a workable audit trail, in the spirit of the daily digest in the Inbox AI Pack: rather than notifying for every single attachment, a grouped end-of-day summary in Slack or Telegram lists the documents received and classified, with an immediate alert reserved for cases where classification failed or returned low confidence. Also set up a dedicated Error Workflow: a corrupted file or a failed API call should never silently disappear — it should land in a manual-retry queue.

Costs and practical limits

With an economical model (GPT-4o mini or equivalent), extracting and classifying a one- to two-page document costs on the order of a cent in input tokens. For an inbox receiving a few dozen attachments a day, the monthly bill stays on the order of a few euros. The real ceiling to watch is the n8n instance's memory rather than API cost: several large attachments processed in parallel (a bulk import, a burst of applications with heavy PDF résumés) can exhaust available RAM under the default binary storage mode — the guide to large files covers the settings to avoid this.

Going further

This pipeline — fetching, security filtering, extraction, classification, routing, archiving — naturally complements the email sorting in the Inbox AI Pack (€79): where the pack sorts and prioritizes the message itself, this guide handles what's attached to it. If the goal goes beyond simple classification and aims to make your entire archived document set searchable in natural language, the RAG Assistant Pack (€119) reuses a very similar ingestion architecture to build a document chatbot on top. And if your industry requires proving who processed which document, when, and with what result, the Compliance & Audit Pack (€149) provides the ready-to-connect Supabase logging building block behind this kind of pipeline.