2026-07-18

How to Share AI-Generated HTML in Confluence

A practical workflow for deciding when Confluence should import, embed, or simply link to an AI-generated HTML report through BinHTML.

developer workflowConfluenceAI-generated HTMLHTML artifactsagent handoff

Reviewed: July 18, 2026.

Table of contents

  1. Start with the Confluence job
  2. When Confluence import is the right move
  3. When an iframe or HTML macro is enough
  4. When to publish a BinHTML link instead
  5. Add the link to Confluence with review context
  6. Automate the handoff with API or MCP
  7. Final checklist

Start with the Confluence job

Confluence is usually the place where a team keeps project knowledge: specs, incident notes, research, release plans, decisions, and operating docs. That makes it a natural place to point reviewers at generated work.

AI-generated HTML creates a sharper decision than a normal document. The output might be a one-off report, dashboard, calculator, prototype, diagram, appendix, or review packet. It may contain CSS and JavaScript. It may need a current version, a source audit trail, or expiry after the review window.

So the first question is not "can Confluence hold HTML?" The better question is: should this generated HTML become Confluence content, appear inside the Confluence page, or stay as a managed artifact linked from Confluence?

When Confluence import is the right move

Atlassian's Confluence Cloud docs describe an HTML import flow that creates a Confluence space from uploaded HTML content. The same docs note that users need permission to create a space before importing HTML, and the FAQ points admins at attachment-size and visibility considerations.

That import path is useful when the HTML is really source material for Confluence documentation. Examples include migrated documentation, legacy static pages, or generated written content that should become editable Confluence pages.

Use Confluence import when:

  • the output should become Confluence-owned documentation
  • the team expects to edit the imported content in Confluence
  • the HTML is part of a migration or knowledge-base buildout
  • permissions can be reviewed before the content is exposed
  • the output does not need a separate artifact lifecycle

Do not use import just because an agent returned HTML. A generated dashboard or prototype may render better as a browser artifact than as converted Confluence content.

When an iframe or HTML macro is enough

Atlassian's iFrame macro docs say the macro embeds a webpage inside a Confluence page or live doc. Atlassian's visual macro index also frames the iFrame macro as a way to preview website content inside Confluence.

That can be useful when the page should show a live external surface near the discussion. For example, an internal dashboard with an approved embed policy may belong inside the Confluence page where the team reviews it.

There are practical limits. Atlassian documents known iframe issues, including websites that block iframe rendering and browsers that block loading as a security precaution. Third-party Confluence HTML macro products also exist for teams that want to render attached files, custom code, or AI-generated snippets inside Confluence, but those tools introduce their own app, allowlist, and admin-review decisions.

Use an iframe or approved HTML macro when:

  • the Confluence admin has approved the embedding approach
  • the embedded source is trusted and allowed
  • reviewers benefit from seeing the surface inline
  • blank iframe behavior, height, scrolling, and browser restrictions are acceptable
  • the artifact does not need BinHTML-specific source, version, expiry, or project controls

If the generated HTML needs to be reviewed as its own deliverable, a link is usually cleaner than an embedded frame.

When to publish a BinHTML link instead

Publish the generated HTML to BinHTML when the output should stay a review artifact rather than becoming a Confluence page.

That usually applies when the HTML is:

  • generated by Claude, ChatGPT, Codex, Cursor, Gemini CLI, Windsurf, or another agent
  • a report, dashboard, prototype, explainer, appendix, or review packet
  • updated over time while the Confluence page should keep one current URL
  • shared with reviewers who should not edit the source in Confluence
  • part of a multi-artifact handoff
  • something that should be revoked, expired, or kept private or unlisted

BinHTML is not a replacement for Confluence and it is not general website hosting. It publishes complete HTML documents as managed artifact links. That is useful when a Confluence page needs to reference the current generated output without absorbing the raw HTML.

For the broader workflow, start with the guide to publishing AI-generated HTML.

Add the link to Confluence with review context

A Confluence page should not just contain a pasted URL. It should tell readers what the artifact is, why it exists, and what decision they need to make.

A practical section can look like this:

```text

Generated HTML review artifact

Link: https://binhtml.com/a/example-slug

Owner: Product ops

Visibility: unlisted review link

Review ask: Check the scenario assumptions, table labels, and recommended next steps.

Update policy: I will update the same artifact link after revisions so this Confluence page keeps one current URL.

`

Use one artifact link for one generated output. Use a project link when the Confluence page points to a packet of related outputs, such as a summary, appendix, scenario comparison, and source notes.

If the artifact includes sensitive data, credentials, customer names, or internal URLs, run a preflight before adding it to a shared Confluence page. The post on preventing unlisted share link leaks covers the link-handling side, and source access covers the audit-trail side.

Automate the handoff with API or MCP

If a person publishes one generated report, the BinHTML dashboard is enough. If an agent creates Confluence-bound HTML repeatedly, make publishing part of the workflow.

Use the BinHTML API when a script, CI job, or backend service already has the HTML and knows which project should own it. Use BinHTML MCP when an agent is still assembling the artifact and should return a Confluence-ready handoff block as part of its final answer.

A useful agent instruction is explicit about the boundary:

```text

Create the HTML review report, publish it to BinHTML as an unlisted artifact in the Confluence Reviews project, then return a Confluence-ready block with the share URL, owner, review ask, visibility, and update policy. Do not paste the raw HTML source into the Confluence page.

`

That keeps Confluence as the decision record while giving the generated HTML a lifecycle outside the page.

Check /pricing before hard-coding project links, private artifacts, retention, or larger limits into an automated workflow.

Final checklist

Before sharing AI-generated HTML in Confluence, check this:

  • The HTML should become Confluence content, appear as an approved embed, or stay as a managed artifact link.
  • The Confluence page explains what reviewers should do.
  • The artifact title is specific enough to find later.
  • Visibility matches the page audience.
  • Expiry and retention match the review window.
  • Source access is available when reviewers need an audit trail.
  • Multi-artifact work uses one project link instead of a stack of URLs.
  • The raw HTML is not pasted into a knowledge-base page when a review link would be safer.

Confluence should hold the project context and decision record. BinHTML should hold the generated HTML when that output needs review controls, versions, source access, or an external handoff.

Sources