How to Publish an HTML Report From an n8n Workflow

Table of contents

1. n8n can build the report, but the last step decides how it lands
2. Why not just paste the HTML or make a Gist
3. Build the HTML in n8n
4. Publish it with an HTTP Request node
5. Pass the link downstream and store it
6. Keep recurring reports on one stable link
7. Questions people also ask

n8n can build the report, but the last step decides how it lands

n8n is a workflow automation tool, and it already has the pieces to produce HTML. The HTML node has a Generate HTML Template operation that turns workflow data into markup, and community workflows commonly assemble a report from data nodes, a Markdown or template step, and a final HTML string.

The interesting decision is the last node. Once the HTML exists, an automation has to deliver it, and the delivery method decides whether the recipient gets something useful or something broken.

Common outputs teams generate in n8n:

• a scheduled metrics or KPI report
• a daily or weekly digest built from several data sources
• an incident or monitoring summary
• a customer-facing status or usage recap
• a QA or data-quality report

BinHTML publishes complete HTML documents as sandboxed, managed share links. That makes it a natural final node for an n8n report workflow. For the broader picture, see the complete guide to publishing AI-generated HTML.

Why not just paste the HTML or make a Gist

Two shortcuts are popular in n8n, and both have real drawbacks.

Pasting the HTML into an email body: most email clients strip scripts, drop styles, and mangle layout, so an interactive or richly styled report degrades or breaks. Recipients also cannot re-open a stable URL later.

Publishing to a raw Gist and previewing it: this returns a URL, but it is a bare file with no ownership controls, no expiry, no visibility settings, and no source-versus-rendered separation. It is fine for a throwaway snippet, not for a report that a colleague or client will review and trust.

A managed artifact link solves both: the report renders in a sandbox, the link is owned and revocable, you can set visibility and expiry, and updating the report can reuse the same URL.

Build the HTML in n8n

Assemble the report as a single self-contained HTML document before the publish step:

• gather data with your source nodes (HTTP, database, spreadsheet, API)
• shape it with a Set, Code, or Markdown node
• render final markup with the HTML node's Generate HTML Template operation, or build the string in a Code node
• keep all CSS and JavaScript inline so the file stands alone
• strip anything that should not be public: secrets, tokens, raw customer records

The output of this stage should be one HTML string on a field you control, for example html. Self-contained HTML is the single biggest factor in whether the published link renders correctly. See keep generated HTML self-contained before you share it.

Publish it with an HTTP Request node

Add an HTTP Request node as the publish step. Point it at the BinHTML publishing endpoint with a POST request:

1. Method: POST, URL: the BinHTML artifacts endpoint from the API docs.
2. Authentication: send your API key in the header the docs specify.
3. Body: JSON that carries the HTML string, a title, visibility, an optional project name, and an optional expiry.
4. Response: read the returned share URL and management fields from the node output.

Because this is deterministic and code-owned, the API is the right surface here rather than an agent. Configure retries and error handling on the node so a transient failure does not drop the run silently. The BinHTML API docs list the exact field names, the auth header, and the response shape.

Pass the link downstream and store it

After the HTTP Request node returns, the workflow has a clean URL to work with. From there:

• send the share URL in a Slack message, email, or ticket instead of the raw HTML
• include a one-line purpose and the reporting period
• store the URL, artifact id, and run timestamp in your database or a log node so you can trace which run produced which report
• record the visibility and expiry you set

Sending a link rather than an attachment also avoids the delivery problems that break HTML in email clients. See share AI-generated HTML in Slack for the messaging side of the handoff.

Keep recurring reports on one stable link

Most n8n reports run on a schedule, so the naming pattern matters. Use a stable project name for the workflow and put the run date in the artifact title, for example Weekly revenue report, 2026-07-20. That keeps a single project handoff useful across every run instead of scattering a new orphan URL each time.

If a reviewer needs to compare this week against last week, keep the prior artifact rather than overwriting it, and link both from the project. See use stable project names for recurring HTML workflows and ship recurring AI reports without sending a new URL every time.

Questions people also ask

How do I share an HTML report generated in n8n?

Add an HTTP Request node that POSTs the HTML to the BinHTML API, then send the returned share URL in your Slack, email, or ticket node. The recipient opens one managed link.

Can n8n turn HTML into a shareable URL?

Yes. n8n has no hosting of its own, but an HTTP Request node can publish the HTML to a service like BinHTML and read back a browser-ready URL, which the rest of the workflow can use.

How do I publish HTML from an n8n workflow without hosting it?

Call a publishing API from an HTTP Request node. BinHTML stores and sandboxes the HTML and returns a managed link, so you do not run any hosting infrastructure yourself.

Should an n8n HTML report go in the email body or behind a link?

Behind a link. Email clients strip scripts and break styling in HTML bodies, so a styled or interactive report should be published as an artifact and sent as a URL.

Final thought

n8n is good at building an HTML report from many sources. The step that decides whether it lands well is the last one. Make the final node a publish to a managed artifact link, pass the URL downstream, and keep recurring runs on a stable project so every report is a clean, trustworthy link instead of a broken email body or an orphan Gist.