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, which is why a Document360 to Notion migration is a rebuild rather than an import. 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)

Content Audit Before You Export

Before running a single export, audit the knowledge base you are actually moving. A content audit pass typically surfaces articles that should be archived rather than migrated, redundant content that will create duplicate pages in Notion, stale articles with outdated screenshots or version-specific instructions, and orphaned articles that are not linked from any category tree. Migrating without auditing means you carry the debt forward — and reformatting 500 articles in Notion is more expensive than reformatting 350.

Use the Document360 CSV export (see above) as your audit input. It gives you titles, categories, status, last-updated dates, and URLs without pulling body content. Sort by last-updated date, filter by status, and flag articles for archive or merge before building your migration manifest.

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.

Block Chunking in Practice

To make the 1,000-block ceiling concrete: suppose a Document360 article parses to 240 blocks (60 paragraphs, 12 headings, 8 code blocks, 20 images, and assorted list items). That fits in a single API call. A longer article that parses to 1,400 blocks must be split. A minimal chunking approach:

1. Parse the full article into a flat block list.
2. Slice the list into chunks of 90 blocks (staying under the 100-children limit with headroom).
3. Call POST /v1/pages with the first chunk as children to create the page.
4. Call PATCH /v1/blocks/{page_id}/children for each subsequent chunk in sequence.
5. After each call, check the response for the id of the last block written — use it to verify ordering before the next append.

This sequence must be idempotent. If a call fails at chunk 3 of 5, your script needs to resume from chunk 3 rather than restart from the beginning, or you will create duplicate content.

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 before migration:

Option A: Single database with a Language property Add a Language select property to your articles database. Create filtered views per language. This keeps all content in one place and is simpler to maintain, but it offers no access segregation by language — every user sees every language in the underlying database.

Option B: Separate page trees or databases per language Create a distinct top-level page or database for each language. This enables separate access controls and ownership, but doubles (or triples) your structural overhead and makes cross-language content comparisons harder. It also means running the migration pipeline once per language.

Choose Option A if language variants share the same audience and access rules. Choose Option B if different languages have separate owners, separate review workflows, or different access restrictions.

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 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. Note that notion.site (public sharing) and notion.so (the workspace URL) serve different purposes: notion.site is for public-facing pages but provides limited SEO configuration compared to Document360's per-article meta 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)

Redirect Strategy for Public-Facing Knowledge Bases

If your Document360 project was public-facing — meaning external users or search engines linked directly to yourproject.document360.io/docs/article-slug URLs — migration breaks every one of those inbound links. Internal link rewriting handles links inside your content, but it does nothing for external links that land on your old Document360 domain.

Before cutover, export your full article URL list from Document360 (the CSV export gives you this) and map each legacy URL to its new Notion equivalent. With that redirect map in hand, your options are:

• If you controlled a custom domain on Document360: Set up 301 redirects at the DNS/proxy layer pointing legacy slugs to the corresponding Notion pages or a new documentation host.
• If you used the default document360.io subdomain: You cannot configure server-side redirects after the project is deleted. Your only option is to publish a redirect index page or update every external source (support emails, product UI links, partner docs) before decommissioning the Document360 project.
• SEO impact: 301 redirects pass link equity. No redirect means any search ranking accumulated by your Document360 articles is lost. For teams migrating high-traffic public documentation, this is a material cost to weigh before choosing Notion as a destination — notion.site pages are indexable but offer limited per-page SEO controls compared to a dedicated documentation platform.

Build the redirect map as part of the pre-migration content audit, not after go-live.

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

The edge cases below are not equally likely or equally costly. The first two are the most common and the most disruptive; the rest are real but narrower in scope.

High frequency / high migration cost

• 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. This affects every project that was migrated to the Advanced WYSIWYG editor without converting older articles.
• Internal link breakage. Projects with dense cross-referencing between articles will have hundreds of broken links after import if the two-pass rewrite is skipped. The larger the knowledge base, the higher the compounding cost of manual repair.

Medium frequency / recoverable

• 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.
• 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.
• 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.

Lower frequency / narrow scope

• 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 has not publicly documented a duplication rate limit. If your migration script uses Notion's duplicate or move page operations internally, test against a large page set in staging before production — behavior at high volume is not guaranteed.

Rollback Plan and Migration Staging

API-based migrations can fail mid-run. A 500-article migration that fails at article 340 leaves your Notion workspace in a partial state — some pages exist, some do not, internal links written in the completed batch point to pages that may not yet exist.

Before any production run, set up a staging environment:

• Create a separate Notion workspace or a dedicated test page tree for dry runs. Run the full pipeline against it before touching production.
• Log every created Notion page ID alongside the source Document360 article ID and slug. Write this to a persistent store (a database, a CSV) as each page is created — not after the run completes. If the pipeline fails, this log tells you exactly where to resume.
• Make the pipeline resumable by article ID, not restartable from scratch. A restart duplicates already-created pages; a resume from a checkpoint does not.
• To roll back a partial import, use the logged Notion page IDs to delete only the pages created in the failed run. The Notion API supports page deletion via DELETE /v1/blocks/{id}. Delete in reverse creation order to avoid orphaned child pages.

Test the rollback procedure in staging before the production migration. A rollback you have never run is not a rollback.

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.