Document360 to Notion Migration: Data Mapping, API Limits & Methods

Migrating from Document360 to Notion is a content-architecture translation problem. Document360 organizes knowledge in a rigid hierarchy — Project → Workspace → Language → Category → Article — with up to six levels of nested subcategories and three distinct category types (Folder, Index, Page). Notion is a block-based workspace where every heading, paragraph, image, and toggle is an individual block, pages nest freely inside other pages, and databases provide relational structure through properties and relations.

A ZIP export from Document360 gives you raw files. It does not rebuild your hierarchy, rewrite internal links, re-host media, or respect Notion's API payload ceilings. If you attempt to use Notion's native UI importer with a large knowledge base, you will hit rate limits that stretch a 500-article import across multiple days of staggered batching. Understanding the structural mismatch before you export a single article is what separates a clean migration from weeks of manual cleanup.

This guide covers the export options on the Document360 side, the hard import and API constraints on Notion's side, the object-mapping decisions you need to make, the edge cases that break most DIY attempts, and the viable migration methods with their trade-offs. If you are evaluating whether Notion is the right target, see our Notion vs. Confluence comparison for an architectural breakdown of both platforms. For a different destination entirely, compare these constraints against our Document360 to Confluence migration guide.

Why Teams Move from Document360 to Notion

The migration drivers are consistent across the teams we work with:

• Tool consolidation. Document360 is a dedicated knowledge base platform. Teams already running Notion for project management, sprint boards, and internal wikis want to collapse their documentation into the same workspace rather than pay for a separate tool.
• Cost pressure. Document360 moved to fully sales-led pricing with no free tier as of late 2024. Notion's per-member pricing is significantly lower for teams that do not need purpose-built KB publishing features like approval workflows, decision trees, or reader analytics.
• Flexibility over structure. Document360's rigid category hierarchy is powerful for structured public-facing documentation but limiting for teams that want to cross-reference docs with project databases, embed live data views, or build custom dashboards alongside their knowledge base.

The trade-off is real: you lose Document360's dedicated KB publishing features — built-in search analytics, article-level SEO controls, ticket deflection metrics, and structured workflow approvals. Make sure your team does not need those before committing to the migration.

Why the Migration Is Technically Complex

The core friction is the data model mismatch. Document360 enforces a strict, unchangeable tree structure with permissions and inheritance flowing downward through a fixed path. Notion does not enforce this structure. A page in Notion can contain text, an inline database, and sub-pages simultaneously.

When moving from Document360, you must decide how to represent categories. Do categories become Notion databases with articles as rows? Or do categories become parent pages with articles as nested sub-pages? If you map this incorrectly, you lose the ability to filter, sort, and manage access effectively.

Document360 categories are not just folders. They can be Folder (pure container, no content, no URL), Index (auto-generates a listing page), or Page (has its own editable body content like an article). (docs.document360.com)

Permissions add another layer of complexity. Document360 lets you grant or deny access at the workspace, category, and article levels, and article restrictions can override category access. (docs.document360.com) Notion teamspaces help organize access, but they are not a 1:1 replacement for a knowledge-base permission model. Treat permission mapping as a redesign task, not an import checkbox.

Document360 Export Methods: ZIP, CSV, API, and Their Limits

Document360 provides three export paths. Each has hard constraints that affect your migration strategy.

ZIP Export (UI-Based)

The primary export method. Navigate to Content Tools → Import & Export → Import and export project and click Export.

• Articles created in the Markdown editor export as .md files. Articles created in the WYSIWYG or Advanced WYSIWYG editor export as .html files. If you select multiple languages, everything exports as .json. (docs.document360.com)
• You can include media files by checking the Include media files option.
• The exported ZIP contains a Media folder and a workspace_slug folder with articles, categories, and a JSON manifest file (workspace_slug_category_articles).

A practical consequence of the format split: if you want to use Notion's native Markdown or HTML importer, export each language separately whenever possible instead of taking one multi-language JSON dump.

CSV Export (Metadata Only)

Export Project API

The API-based export endpoint has two critical constraints:

1. Plan requirement: You must be on a Business or Enterprise plan to use the export project API endpoint. Standard and Professional plans cannot trigger a project export via API.
2. Rate limit: The export API is capped at 2 calls per day. Exceed this and you receive a 400 error: "Export API request limit(2) is reached for the day."

For article-level API reads (listing articles, fetching content), Document360 enforces per-minute rate limits tied to your plan tier:

Every API call counts as one request. The API is authenticated via a static API key passed in the api_token header — no OAuth flow. Monitor the X-RateLimit-Remaining header in every response. Once the limit is hit, the API returns HTTP 429. Build exponential backoff into any extraction script.

Do Not Confuse ZIP with WebHelp

Document360 also offers a WebHelp export for offline browsing that preserves navigation and internal links. But attachments are explicitly excluded from WebHelp exports. If attachments or downloadable files matter, WebHelp is the wrong migration source. (docs.document360.com)

Notion Import and API Limits You Must Plan For

Notion's constraints hit from two directions: the native UI importer has throughput caps, and the API has payload size and rate limits that break naive migration scripts.

Native File Importer

Notion's built-in importer accepts Markdown, HTML, Word, and CSV files via Settings → Import.

• Rate limit: Approximately 120 file imports every 12 hours. For a 500-article knowledge base, that is at minimum 5 import batches spread across 60+ hours.
• File size limits: 5 MB per file on the Free plan, 50 MB per file on paid plans (Plus, Business, Enterprise). (notion.com)
• No progress tracking. There is no progress bar or status indicator during import.
• Timestamps are lost. The importer does not preserve original created or updated dates from your source files.
• Formatting loss. H4+ headings are normalized to H3. Anchor links and nonstandard Markdown extensions may not import cleanly. Complex HTML layouts, scripts, embeds, and comments are flattened. (notion.com)

Notion API Constraints

The API is the only path for a controlled, high-fidelity migration. But it enforces hard limits:

Rate-limited requests return HTTP 429 with a Retry-After header:

{
  "object": "error",
  "status": 429,
  "code": "rate_limited",
  "message": "Rate limited. Please retry after 1 second."
}

The 1,000-block payload ceiling is the constraint that catches most migration scripts off guard. A long Document360 article with 80 paragraphs, 15 headings, 20 images, and nested lists can easily exceed 1,000 blocks when translated to Notion's block model. Your migration script must chunk these into multiple Append Block Children requests, each staying under the 100-children-per-request limit.

For teams building custom scripts, these practical guardrails leave headroom below the published API caps and reduce 429 errors during long runs:

notion_write_budget:
  target_rps: 2.5
  append_children_batch: 100
  page_payload_budget_blocks: 900
  page_payload_budget_bytes: 450000

Those numbers are not official Notion limits. They are sensible defaults that reduce churn during extended migration runs. (developers.notion.com)

For a detailed breakdown of all Notion import paths, see our guide to importing data into Notion.

Data Mapping: Document360 Hierarchy to Notion Architecture

This is where most migrations go wrong. Document360's hierarchy is rigid and purpose-built for structured documentation. Notion's is flexible and freeform. You need to make explicit mapping decisions before writing any migration code.

Structural Mapping

Handling Multi-Level Categories

Document360 supports up to 6 levels of subcategories (7 total including the root). Notion has no hard nesting limit for pages, but deeply nested page trees become unwieldy to navigate. Our recommendation:

• Levels 1–3: Map directly to nested Notion pages.
• Levels 4–6: Flatten into a Notion database with a "Parent Category" relation property. This preserves the hierarchy as queryable metadata without burying content six levels deep in the sidebar.

Handling Multi-Language Content

Document360 supports adding languages to a workspace, and the article APIs report available_languages and fallback behavior when a requested language version is unavailable. Notion has no built-in localization support, so you need an explicit decision:

• If your Notion users browse by language, build a visible Language property on a database and create filtered views per language.
• If languages have separate owners or separate access rules, split them into separate top-level trees or databases entirely.

Preserving Legacy Metadata

Two fields are especially valuable for cutover: url and slug. Document360's article list endpoint exposes both, along with order, parent_category_id, language_code, and visibility flags. Store all of them as Notion database properties even if end users never see them. They are what make deterministic replays, redirect maps, and broken-link QA possible. (apidocs.document360.com)

Translating Content to Notion Blocks

Document360 exports articles as Markdown or HTML. The Notion API does not accept raw Markdown or HTML for page creation. You must parse the source content and translate it into Notion's JSON block arrays.

For example, a Document360 H2 header becomes:

{
  "type": "heading_2",
  "heading_2": {
    "rich_text": [{
      "type": "text",
      "text": { "content": "Your Header Text" }
    }]
  }
}

At extraction time, do not guess format from file extension alone. The article API endpoints return both the editor type and the body fields — content for Markdown and html_content where applicable. Use that metadata to route each item through the correct Notion transform. (apidocs.document360.com)

Failing to accurately parse tables, code blocks, callouts, and nested lists during this translation phase results in broken formatting across the entire Notion workspace.

What Does Not Transfer

These Document360 features have no direct Notion equivalent:

• Approval workflows and publishing states — Notion has no built-in content governance workflow.
• Reader analytics (views, search terms, feedback) — lost entirely.
• Decision trees — must be rebuilt using Notion toggles or linked databases.
• Article-level SEO settings — Notion pages published via notion.site have minimal SEO controls.
• Content reuse (snippets, variables) — partially replaceable with Notion's synced blocks, but the mapping is manual.
• Role-based content access at the category level — Notion's permission model works at the page/database level, not at a "category" abstraction.

Handling Media, Attachments, and Internal Links

Media Files

The Document360 ZIP export stores media in a dedicated Media folder. During migration, each file must be uploaded to Notion and the corresponding block references updated.

Via the native importer: Media referenced in Markdown/HTML files may render if they use relative paths that match the export structure. But images hosted on Document360's CDN (files.document360.io) will break if that CDN is decommissioned after migration.

Via the API: Use the File Upload API to upload each media file to Notion's storage. Files under 20 MiB can be uploaded in a single request. Files over 20 MiB require multi-part upload. Every uploaded file must be attached to a block or page within one hour or it expires. Run media migration as a pipeline alongside content import, not as a manual side task afterward. (developers.notion.com)

Internal Links

This is the highest-effort part of any knowledge base migration. Document360 internal links use URL patterns like:

https://yourproject.document360.io/docs/article-slug

After migration, those URLs are dead. Every internal link in every article must be rewritten to point to the corresponding Notion page. This requires a two-pass approach:

1. Pass 1 (Creation): Create all Notion pages and build a lookup table mapping each Document360 slug to the new Notion Page ID.
2. Pass 2 (Rewrite): Scan all Notion blocks for Document360 URL patterns. Replace them with native Notion page references using the lookup table.

Manual migrations almost always skip this step, leaving dozens or hundreds of broken links.

Heading Anchors

Heading anchors deserve separate treatment. Notion's importer does not preserve Markdown anchor links, but every Notion block has its own shareable link. In practice, you either drop old heading anchors, replace them with page-level links, or run a second pass that maps known legacy anchors to Notion block links for high-value articles. Treat this as an explicit scope decision, not an afterthought. (notion.com)

Migration Methods Compared

There are three realistic approaches. Here is what each actually involves.

Method 1: Manual ZIP Export → Notion Importer

Best for: Fewer than 50 articles, minimal internal links, simple formatting.

1. Export your Document360 project as a ZIP (include media files).
2. Extract the ZIP. Separate .md and .html files.
3. Import Markdown files into Notion via Settings → Import → Markdown. HTML files may need conversion to Markdown first (using a tool like pandoc) or import as HTML.
4. Manually recreate your category hierarchy as nested Notion pages.
5. Fix broken internal links by hand.

Throughput ceiling: ~120 files per 12 hours. A 200-article KB takes 2+ days of batched imports.

What you lose: Original timestamps, internal link integrity, media re-hosting (manual), hierarchy structure (manual rebuild), metadata properties.

Method 2: iPaaS Automation (Zapier, Make)

Tools like Zapier and Make can connect Document360 triggers to Notion actions. In practice, this is limited to new article creation sync, not historical bulk migration. The Notion API's 3 req/sec limit and 1,000-block payload ceiling mean these tools hit 429 errors on any non-trivial batch, and most iPaaS platforms do not handle block-level content chunking.

Verdict: Not a viable migration method. Potentially useful for ongoing sync of new articles after migration.

Method 3: Custom API-to-API Migration Script

Best for: Any knowledge base with 50+ articles, complex hierarchy, or internal link dependencies.

1. Extract articles via Document360's REST API (GET /v2/Articles) at 60–100 req/min depending on plan.
2. Parse HTML or Markdown content into Notion's block schema (paragraph, heading, image, code, callout, etc.).
3. Create the page hierarchy in Notion using POST /v1/pages and PATCH /v1/blocks/{id}/children.
4. Upload media via the File Upload API, updating block references.
5. Rewrite internal links using the slug-to-page-ID lookup table.
6. Handle rate limits on both sides with queue management and exponential backoff.

This is the only method that preserves full structural fidelity. It is also the most engineering-intensive — expect to handle block chunking (1,000-block ceiling), nested block depth limits (2 levels per request), rich text character limits (2,000 per block), and dual rate limit orchestration.

Edge Cases That Break Most Migrations

• Mixed editor types. If your Document360 project uses both Markdown and WYSIWYG editors across different articles, the ZIP export contains a mix of .md and .html files. Your migration pipeline must handle both formats and route each through the correct parser based on the editor type metadata from the API.
• Replicated articles. Document360 allows articles to appear in multiple categories via the Replicate feature. Notion has no equivalent. Decide whether to duplicate the page or use a database relation to represent the multi-category association.
• Category type semantics. D360's three category types (Folder, Index, Page) behave differently. Folders have no URL or content. Index categories auto-generate a listing page. Page categories have editable content. Your mapping logic must handle all three — a single generic "create page" function will not work.
• Language variants. Multi-language projects export differently depending on whether you select one or multiple languages. Single-language exports produce .md/.html files; multi-language exports produce .json. Your parser must handle both formats.
• Notion CSV relation gap. Notion's CSV importer creates databases where rows become pages and columns become properties, but it cannot map relation properties during import. Relations, rollups, and formulas must always be rebuilt after the initial import. (notion.com)
• Undocumented Notion duplication limit. Notion reportedly enforces a limit of approximately 50,000 block duplications per hour. If your migration script uses Notion's duplicate or move page operations internally, you may hit this silently.

The ClonePartner Approach

We have migrated knowledge bases with hundreds of articles across platforms with these exact architectural gaps. Here is what we do differently:

• API-first extraction that bypasses the 120-file native import cap entirely. Our scripts pull content directly from Document360's API and write to Notion's API with optimized batching and queue management.
• Automated rate limit orchestration across both APIs — adaptive throttling with exponential backoff handles Document360's 60–100 req/min limits and Notion's 3 req/sec ceiling without manual intervention.
• Block-level content translation — we parse Document360's HTML and Markdown into Notion's block types directly, preserving callouts, code blocks, nested lists, tables, and image embeds without lossy conversion.
• Internal link rewriting — our pipeline maintains a full slug-to-page-ID mapping and rewrites every internal Document360 link to a native Notion page reference.
• Media re-hosting — every image and attachment is uploaded to Notion's storage via the File Upload API, so nothing depends on Document360's CDN after cutover.

If you are worried about data portability after migrating to Notion, see our guide on how to export data from Notion — knowing your exit options before you enter a platform is smart engineering.