Confluence to Document360 Migration: API Limits & Data Mapping Guide

There is no native, one-click migration path from Confluence to Document360. Document360 does not offer a built-in Confluence importer. Their official migration process asks you to export Confluence spaces as Word documents and hand them to the Document360 team. That approach works for small, text-heavy spaces — but it silently destroys macros, strips metadata, caps images at 50 per page, and flattens your page hierarchy.

If you are migrating a large, macro-heavy Confluence instance, data fidelity is your biggest risk. This guide covers the architecture differences between Confluence and Document360, the hard API limits on both sides, the exact data-mapping decisions you'll face, what can and cannot be migrated, and the edge cases that cause silent data loss.

For a deep dive on extracting data from Confluence before starting any migration, see How to Export All Data from Confluence: Methods, Limits & Tools.

Why Move from Confluence to Document360?

The most common driver is a shift from an internal collaboration wiki to a structured, customer-facing knowledge base. Confluence excels at internal team collaboration — it's a wiki with rich macros, deep Jira integration, and flexible page trees. But it was never optimized for publishing polished external documentation with custom branding, SEO controls, versioning, and reader analytics.

Document360 is purpose-built for that use case. Teams moving to Document360 typically want cleaner category navigation, built-in article versioning and workflows, dedicated API documentation features, and AI-powered search for end users. For teams still evaluating whether Confluence is the right fit, see our Confluence Alternatives (2026) breakdown.

The risk in this migration isn't the decision to move — it's the method of moving. The wrong approach silently drops content you won't notice until customers report missing docs.

The Architecture Clash: Confluence Spaces vs. Document360 Categories

Understanding the structural mismatch between these two platforms is the first step to planning a clean migration.

Confluence organizes content into Spaces, each containing a tree of Pages with unlimited nesting depth. A typical Confluence instance has multiple spaces (e.g., Engineering Docs, Product Docs, API Docs), and each space has its own page hierarchy, permissions, and blog stream. Pages can be nested 10, 15, or 20 levels deep — there is no enforced limit.

Document360 uses a Project → Category → Subcategory → Article hierarchy. You can create up to seven levels of categories (1 root category + 6 subcategory levels). You can create up to 1,000 categories per workspace. The character limit for article or category titles is 300, including spaces.

This creates a hard mapping problem:

Document360 Category Types Matter

The biggest modeling mistake is treating every Confluence page as if it were just a Document360 article. Document360 has three category types, and the type you choose affects URL behavior (docs.document360.com):

• Page category: Can hold its own content and contain child categories and articles. Use this for Confluence parent pages that have both body content and children.
• Index category: Generates a shareable URL and acts as a landing page for the items inside it. Use this for Confluence parent pages that serve as navigation hubs.
• Folder category: A simple container with no standalone URL. If the source Confluence page has inbound links or meaningful body content, mapping it to a Folder creates a link-target problem.

Safe rule: if a Confluence page needs its own URL in the target, do not map it to a Folder. Use Page or Index instead.

The practical recommendation: map each Confluence Space to a Document360 Project (if you're on an Enterprise plan with multiple projects) or to a root Category (if consolidating into a single project). Then map top-level pages to categories and child pages to subcategories, collapsing anything beyond level 6.

The Problem with Document360's "Word Export" Migration Method

Document360's official blog describes their migration approach: "Export your Confluence spaces in Word format and share them with the Document360 team – it's that simple!" Document360's migration experts take over – setting up the migration strategy, analyzing your content, and outlining the timeline and phases.

For small documentation sets with mostly static text, this works well enough. But for any Confluence instance that uses macros, embeds, or has image-heavy pages, the Word export path introduces silent data loss at multiple points.

What the Word Export Drops

1. Images beyond the 50-image cap

Only the first 50 images attached to the page are exported to your Word document. This is to prevent out of memory errors affecting your whole Confluence site. If a page contains more than 50 images, Exporting to Word will create a document with only 50 first images. All extra images will appear as empty boxes.

This is a hard limit enforced by Atlassian. If your documentation includes screenshot-heavy tutorials or visual product guides, entire sections will export with broken image placeholders — and no warning in the export log.

2. Dynamic macros

Confluence macros like Jira Issues, Roadmap, Chart, Table Filter, and any third-party Marketplace macros do not render in Word exports. They either appear as empty <div> blocks or are stripped entirely. The elements made with macros (Table of Contents or Tabs) are not shown because macros don't create elements with natural HTML.

3. Internal links

Confluence internal links (e.g., [Page Title|SPACEKEY:Page Title]) resolve to Confluence URLs in the Word export. These become dead links in Document360 unless every link is manually rewritten post-migration.

4. Page metadata

Labels, page properties, restrictions, version history, and comments are all stripped in the Word export. None of this metadata carries over.

5. File format and size constraints

Due to the format of this file, it can only be opened in Microsoft Word and is not compatible with other applications such as Open Office, Libre Office or Google Docs. Document360's self-serve Word importer only supports .docx files under 30 MB and does not support HTML import. Word import is also not supported in Document360's Markdown editor — only the WYSIWYG editor. (document360.com)

6. Heading-based splitting

Document360 uses heading tags to divide Word imports into multiple articles. Large source files may split unexpectedly if your heading structure doesn't align with how you want articles organized in the target.

Even Document360's own blog distinguishes between its managed service and its public importer: for private spaces, the managed team may work from exported HTML, PDF, or Word files, while the public self-serve importer still only accepts .docx. Do not confuse a vendor-run service with what your team can reliably automate on its own.

API Limits: What Breaks When Building a DIY Migration Script

If the Word export path is too lossy, the alternative is an API-driven migration: read from the Confluence REST API, transform the content, and write to the Document360 API. This is the highest-fidelity approach, but both APIs have hard rate limits that will throttle naive scripts.

Confluence Cloud API Limits (2026)

Enforcement of the new points-based API rate limits and tiered quota rate limits for Jira and Confluence Cloud apps will begin on March 2, 2026. This change is designed to ensure consistent performance and fair usage. The new rate limits will apply to all Forge, Connect, and OAuth 2.0 (3LO) apps.

Confluence Cloud uses a points-based model to measure API usage. Instead of simply counting requests, each API call consumes points based on the work it performs—such as the amount of data returned or the complexity of the operation.

This matters for migrations because fetching page content with body.export_view (which renders macros into HTML) is far more expensive in points than fetching body.storage (raw storage format). Using the /rest/content/{id} endpoint with expand=body.export_view triggers the API to render all embedded macros, including Jira Issue macros, putting significant load on the instance.

The token vs. app distinction is critical: API token-based traffic is not affected by this change, and will continue to be governed by existing burst rate limits. If you authenticate your migration script with a personal API token, you avoid the new points-based quotas but remain subject to per-second burst limits. If you're using an OAuth 2.0 app or Forge app, the new points model applies and export_view calls will consume your quota rapidly.

Document360 API Limits

The Document360 API enforces strict per-minute rate limits tied to your subscription tier:

Source: Document360 API docs

Rate limits are applied per api_token - the unique authentication key that identifies your Document360 account when making API calls.

At 60 requests/minute on a Professional plan, a migration of 500 articles (assuming one API call per article creation plus one for each attachment upload) takes a minimum of ~17 minutes just for the write calls — assuming zero retries, zero errors, and no category creation overhead. Realistically, factor in 2–3x that time.

Handling 429s on Both Sides

If your app exceeds its rate limit, Confluence returns an HTTP 429 Too Many Requests response. Your app should handle this gracefully by pausing requests and retrying after the specified delay.

Document360 returns the same HTTP 429 code with X-RateLimit-Reset indicating seconds until the window resets. Your migration script must handle 429s from both APIs independently — reading from Confluence and writing to Document360 are separate rate-limit domains.

import time
import requests
 
def api_call_with_backoff(method, url, headers, json=None, max_retries=5):
    for attempt in range(max_retries):
        resp = requests.request(method, url, headers=headers, json=json)
        if resp.status_code == 429:
            retry_after = int(resp.headers.get('Retry-After', 60))
            print(f"Rate limited. Waiting {retry_after}s (attempt {attempt+1})")
            time.sleep(retry_after)
            continue
        resp.raise_for_status()
        return resp
    raise Exception(f"Max retries exceeded for {url}")

How to Map Confluence Macros and Attachments to Document360

This is where most migrations either succeed or fail silently. Confluence's macro ecosystem is vast — Document360's editor supports Markdown and HTML, but has no macro concept.

Macro Translation Map

Here is an example of translating a Confluence Info Panel macro. The raw Confluence storage format:

<ac:structured-macro ac:name="info">
  <ac:rich-text-body>
    <p>This is a critical system update.</p>
  </ac:rich-text-body>
</ac:structured-macro>

Must be mapped to Document360's Markdown callout format:

:::info
This is a critical system update.
:::

For code blocks, extract the language parameter from the Confluence macro and wrap content in standard Markdown fenced code blocks. For unsupported macros like Expand and user mentions, flatten them into styled HTML or plain text.

Document360's content APIs support Markdown, WYSIWYG (HTML), and Advanced WYSIWYG as separate content types per article. Choose the target content type deliberately based on what each article contains — do not rely on a single default for the entire migration. (apidocs.document360.com)

Attachment Pipeline

Confluence stores attachments at the page level, accessible via the REST API:

GET /wiki/rest/api/content/{pageId}/child/attachment

Document360 stores files in its Drive feature and references them within articles. The migration pipeline must:

1. Download each attachment from Confluence via API
2. Upload to Document360 Drive via API (each upload counts against your rate limit)
3. Rewrite all <img> and <a> references in the article body to point to the new Document360 Drive URLs

If you skip step 3, your migrated articles will contain broken image references pointing back to your Confluence instance — which will break the moment you decommission it.

Keep the attachment pipeline separate from the body transform. Pull binaries through the page-attachments endpoint, upload them into Document360 Drive, then rewrite every src and href against the new file URL.

Internal Link Rewriting

Confluence internal links use the format:

https://yoursite.atlassian.net/wiki/spaces/SPACEKEY/pages/123456/Page+Title

Document360 article URLs follow a different pattern based on your KB slug configuration. The migration must maintain a source-to-target URL map (Confluence page ID → Document360 article slug) and rewrite every internal link in every article body before publishing.

One edge case worth noting: Confluence links created with the "copy link" shortcut can appear in export_view as raw URLs rather than clean page-title anchors. If you rewrite links based only on visible anchor text, you will miss these. Always rewrite from Confluence page IDs and your target slug map. (community.developer.atlassian.com)

This is the single most time-consuming part of a DIY migration. Miss a link, and you get a 404 in your public knowledge base.

What Can and Cannot Be Migrated

Migrates cleanly with an API approach:

• ✅ Page body content (text, headings, tables, lists)
• ✅ Inline images and file attachments
• ✅ Basic macros (code blocks, info/warning/note panels, expand sections)
• ✅ Category hierarchy (up to 6 subcategory levels)
• ✅ Article titles and slugs
• ✅ Internal links (with URL rewriting)

Requires manual mapping or transformation:

• ⚠️ Include/excerpt-include macros (must inline content)
• ⚠️ Jira issue macros (static snapshot only)
• ⚠️ Draw.io/Gliffy diagrams (export as images)
• ⚠️ Page labels → Document360 tags
• ⚠️ Page trees deeper than 7 levels (must restructure)
• ⚠️ Blog posts (Confluence blog → Document360 article, loses chronological context)

Cannot be migrated:

• ❌ Page version history
• ❌ Inline comments
• ❌ Page restrictions (different permission model)
• ❌ Space-level permissions
• ❌ Confluence Analytics data
• ❌ Third-party Marketplace macro functionality (live data, interactive elements)
• ❌ Confluence templates (must recreate in Document360)
• ❌ Page watch/notification subscriptions
• ❌ Original created/modified timestamps or authorship (Document360's create endpoints do not expose fields for backdating) (apidocs.document360.com)

Step-by-Step: API-Driven Migration Workflow

If you're building this yourself, here is the workflow:

Step 1: Audit and Map Your Confluence Content

• Export a list of all spaces and pages using the Confluence REST API
• Identify macro usage per page using CQL: macro='macroName' AND space=SPACEKEY
• Flag pages with >50 images, include macros, or third-party macros
• Identify newer Confluence object types (whiteboards, databases) that have no Document360 equivalent
• Map your Confluence hierarchy to Document360's category structure

Step 2: Design the Target Information Architecture

• Decide whether each source node becomes a Folder, Index, Page category, or Article
• Reserve Document360 workspaces for true version or audience splits, not for every Confluence space
• Choose explicit slugs — they must be unique within the project version

Step 3: Extract Content via Confluence API

• Fetch each page's content using body.storage (raw Confluence storage format)
• Separately fetch body.export_view only for pages where you need rendered macro output
• Keep both representations — export_view can produce rendering artifacts for some macros and copied links
• Download all attachments per page
• Record the full page tree structure with parent-child relationships

Step 4: Transform Content

• Parse the Confluence storage format (XML-based with <ac:structured-macro> tags)
• Translate each macro to its Document360 HTML/Markdown equivalent (see the mapping table above)
• Convert inline images from Confluence attachment references to placeholder tokens
• Build the source-to-target URL map for internal link rewriting

Step 5: Create Category Structure in Document360

• Use the Document360 API to create categories parent-first (child categories require parent_category_id)
• Respect the 6-subcategory depth limit — flatten deeper branches as articles at the lowest level
• Set the correct category type (Folder, Index, or Page) based on your architecture decisions

Step 6: Upload Attachments and Create Articles

• Upload each attachment to Document360 Drive via API
• Replace placeholder tokens in article body with actual Document360 Drive URLs
• Rewrite all internal links using the URL map
• Create each article via the Document360 API, assigning it to the correct category
• Choose the right content type per article (Markdown, WYSIWYG/HTML, or Advanced WYSIWYG)

Step 7: Publish and Add Redirects

• Run a separate publish pass after content creation — articles are created as drafts by default
• Respect Document360's per-token rate limits during publishing
• Add 301 redirect rules from old Confluence URLs to new Document360 slugs
• Document360 implements comprehensive SEO configurations and establishes 301 redirects from legacy URLs to their corresponding Document360 pages, ensuring minimal ranking disruption.

Step 8: Validate

• Run an automated comparison: page count in Confluence vs. article count in Document360
• Check for broken internal links in the published KB
• Verify no links still point to *.atlassian.net URLs
• Spot-check macro-heavy pages for formatting accuracy
• Verify image rendering on pages that had >50 images in Confluence

The ClonePartner Approach

We've migrated documentation sets from Confluence to multiple knowledge base platforms, including Document360. Our approach bypasses the Word export path entirely — we work directly API-to-API.

What that means in practice:

• Direct API extraction from Confluence using body.storage, parsing the raw storage format to capture every macro, attachment reference, and structural element.
• Programmatic macro translation — our engine maps supported Confluence macros to their Document360 HTML/Markdown equivalents automatically, rather than relying on lossy Word conversion.
• Automatic hierarchy mapping — we map your Confluence page trees into Document360's category structure, with correct category types (Page, Index, Folder) based on whether each node needs its own URL. Depth overflows are flagged and resolved before the migration runs.
• Built-in rate limit orchestration — our scripts handle both Confluence's 2026 points-based limits and Document360's 60–100 req/min limits with adaptive throttling, exponential backoff, and retry logic. Zero data loss at scale.
• Full link rewriting — we maintain a complete source-to-target ID map and rewrite every internal link before publishing.
• Attachment pipeline — images and files are downloaded, checksummed, re-uploaded to Document360 Drive, and all references are updated in the article body.
• Post-migration validation — automated diff comparing Confluence source data against Document360 articles: page count, attachment count, link integrity.

We complete most Confluence-to-Document360 migrations in days, not weeks.

Post-Migration QA: Validating Your Document360 Knowledge Base

After migration, run these checks before pointing your DNS or publishing your new KB:

Content integrity:

• Total article count in Document360 matches total page count migrated from Confluence
• Spot-check 10% of articles for formatting accuracy (tables, code blocks, headings)
• Verify all images render — especially on pages that had >50 images in Confluence
• Confirm expand/collapse sections work on the published KB site

Links and URLs:

• Run Document360's built-in broken link checker
• Verify internal links between articles resolve correctly
• Confirm no links still point to *.atlassian.net URLs
• Spot-check every parent node that was mapped to a Folder — it will not have a standalone URL
• Crawl internal links and compare 200, 301, and 404 outcomes (bad redirect rules can conflict or create loops)

SEO and redirects:

• Set up 301 redirects from old Confluence URLs to new Document360 slugs
• Verify meta descriptions and article slugs match your SEO requirements
• Check your top traffic URLs and create redirects before cutover

Structure:

• Confirm category hierarchy matches the planned mapping
• Verify no categories exceed the 6-subcategory depth limit
• Check that articles appear in the correct categories on the published site

For a more comprehensive QA framework, see our Post-Migration QA: 20 Tests to Run After Your Helpdesk Migration — many of the same validation principles apply to knowledge base migrations.

Making the Right Call

The Confluence-to-Document360 migration is not technically difficult — it's technically detailed. The data model mismatch (unlimited page depth vs. 7-level categories), the macro translation requirements, and the dual API rate limits mean that the quality of your migration depends entirely on the method you choose.

If your Confluence instance is small, mostly text, and uses few macros, the Word export path via Document360's migration team may be sufficient. Test it on one space first and audit for data loss before committing.

If your instance is large, macro-heavy, or image-dense, the API-driven approach is the only way to preserve content fidelity. Build it yourself if you have the engineering time, or bring in a team that's done it before.

The mistake is not choosing Word export. The mistake is choosing it for a knowledge base that clearly needs object mapping, link rewriting, and controlled publishing. That is how teams end up finished and still months away from a trustworthy help center.