Quip to Notion Migration: Step-by-Step Guide & API Limits

There is no native import path from Quip to Notion. No one-click importer, no direct connector, no Quip option in Notion's import menu. Notion's help center says to export individual pages as Markdown or HTML and import them one at a time. For a workspace with hundreds or thousands of documents, that is not a migration — it is a sentence. (notion.com)

This guide covers the real approaches to moving from Quip to Notion, the API rate limits that bottleneck each one, and the specific data types that break if you do not plan for them.

Why Teams Are Moving from Quip to Notion

Quip has been on a slow feature-retirement trajectory since Salesforce acquired it in 2016. The Windows and Android apps were retired in June 2024. The Upload/Import option was removed in January 2024. New custom live apps stopped being allowed after March 2025, and legacy integrations like X/Twitter and Zapier were retired in July 2025. Salesforce is pushing users toward Slack Canvases and Agentforce. (quip.com)

For engineering, product, and RevOps teams that rely on structured wikis and relational data, Slack Canvases fall short. Notion offers block-based architecture, relational databases, and a broad ecosystem of integrations. It has also been actively shipping: a File Upload API (May 2025), a Markdown-native Create Page endpoint (API version 2026-03-11), and database templates that make it a natural landing zone for structured documentation.

The operational risk of staying on Quip is no longer theoretical. If your subscription lapses, your data enters a deletion pipeline. If you need a deeper look at extraction before you touch Notion, start with our guide to exporting Quip data.

It is worth noting that this import gap is specific to Notion. Coda has a native Quip importer that authenticates with a Quip access token and pulls folders and pages directly. Notion does not. If native Quip ingestion is a deciding factor, Notion starts from a weaker position here. (help.coda.io)

Why Quip to Notion Is Not a One-Click Migration

Two architectural mismatches make this migration genuinely difficult.

Quip is thread-based. Notion is block-based. In Quip, the core unit is a thread. A thread may contain a document or spreadsheet plus its message history. Each paragraph, list item, or table cell carries its own section ID. Quip folders are not true directories — they behave like tags, and a single thread can exist in multiple folders simultaneously. A Quip document can also contain multiple embedded spreadsheets within a single thread. (quip.com)

Notion is structurally different. Every element is a JSON block. Pages nest inside pages in strict parent-child hierarchies. Databases are first-class objects with typed properties, relations, and views. A Quip document with an embedded spreadsheet has no direct analog in Notion — you have to split it into a Notion page for the prose and a separate Notion database for the spreadsheet data, then decide how to link them.

Both APIs enforce hard rate limits. Quip's Automation API defaults to 50 requests per minute per user and 600 requests per minute per company. The Admin Bulk Export API has a separate limit of 36,000 documents per hour. On the Notion side, the public API averages 3 requests per second per integration (this is an unofficial average, not a documented hard cap), append requests cap at 100 child blocks per request, and request payloads are limited to 1,000 blocks and 500 KB. If you build your own importer, queueing, retries, backoff, and chunking are not optional. (quip.com)

If you want the reverse perspective on the data model mismatch, our Notion to Quip migration guide covers the mirror image.

Method 1: Manual Export and Import (HTML/DOCX)

This is the path Notion officially recommends. It works for fewer than ~50 documents. Beyond that, you will lose patience or make mistakes.

Step-by-step process

1. In Quip, open a document, click the document icon (top left), and choose Export → HTML or Export → Microsoft Word.
2. In Notion, go to Settings → Import → HTML (or Text & Markdown) and upload the exported file.
3. Repeat for every document.

HTML is usually the better starting point when you care about layout, images, code blocks, and simple tables. Notion explicitly recommends switching between HTML and Markdown when one format fails. If you have many HTML files, Notion lets you ZIP a folder and import it in bulk — that helps on the Notion side, but it does not remove the Quip-side page-by-page export burden. (notion.com)

What transfers

• Basic text formatting (headings, bold, italic, lists) comes through reasonably well.
• One Notion page per exported file.

What does not transfer

• Comments and chat history — not included in any Quip export format.
• Folder hierarchy — you are importing flat files. You must manually recreate the page tree in Notion.
• Internal links — Quip cross-document links point to quip.com URLs that mean nothing inside Notion.
• Embedded spreadsheets — exported as part of the HTML but import poorly. Notion warns that "complex tables, special callouts, and advanced formatting may degrade."
• Attachments and images — HTML export may embed images, but they often break during Notion import. Quip's Markdown export strips images entirely.
• Live apps and polls — excluded from self-serve import entirely.

Import rate limits

Notion enforces strict file import limits. HTML and Markdown imports are capped at 5 MB per file on the Free plan and 50 MB on paid plans. Both are rate-limited to roughly 120 file imports per 12 hours. ZIP imports can be up to 5 GB, but Notion warns that ZIPs with 10,000+ files are "likely to fail or partially import." (notion.com)

For a workspace with 200 documents, you are looking at 2+ days of manual clicking just for the import step — before any cleanup.

Method 2: API-Based Migration with Open-Source Scripts

If you have engineering resources, you can script the migration using both the Quip Automation API and the Notion API. The most mature open-source tool for this is @topmonks/quip-notion.

How @topmonks/quip-notion works

This Node.js CLI tool connects to both APIs. You provide a Quip developer token, a Notion integration token, and a root Notion page ID. The tool crawls your Quip folder tree, exports each document as HTML, converts it to Notion blocks, and creates pages via the Notion API. (npmjs.com)

npx @topmonks/quip-notion \
  -q "QUIP_TOKEN" \
  -n "NOTION_API_KEY" \
  -root "NOTION_ROOT_PAGE" \
  -s3 \
  --aws-access-key "AWS_ACCESS_KEY_ID" \
  --aws-secret-access-key "AWS_SECRET_ACCESS_KEY" \
  --aws-region "AWS_REGION" \
  --aws-bucket "AWS_BUCKET" \
  -a fs notion

Key features:

• Rate limit handling with state persistence — if the script hits a 503, it saves progress and resumes later.
• Optional image upload to AWS S3 — images extracted from Quip are uploaded to S3, and Notion pages reference those S3 URLs.
• Folder structure preservation — the tool attempts to recreate the Quip folder tree as nested Notion pages.

The catch: you are now managing AWS infrastructure just to move text and images between two SaaS apps. If the state file corrupts during a timeout, you restart the batch.

Notion API authentication scopes required

Before scripting the migration, your Notion integration must have the correct capability scopes enabled. You need: Read content (to verify existing pages), Insert content (to create new pages and databases), Update content (to append blocks and rewrite links), and Read comments (if you are extracting and staging Quip comments as Notion comments). Without all four scopes enabled, the migration script will fail with permission errors at different stages — often not at the start, which makes the failure harder to debug.

API rate limits you will hit

Both sides impose hard limits. Here is the real-world math:

Quip's folder crawl and the double-lookup problem

When crawling Quip's /1/folders endpoint to build the migration hierarchy, the API returns a list of child IDs — but does not distinguish between sub-folders and threads. Every child ID requires a secondary lookup to determine its type. For a workspace with deep folder nesting, this doubles the API call count before a single document is exported. Plan your rate limit budget accordingly, and consider caching the type-lookup results so you do not re-fetch on retry runs.

The image problem (and the new alternative)

Historically, migrating images from Quip to Notion required an intermediate hosting step. The Notion API did not support direct file uploads, so tools like @topmonks/quip-notion route images through AWS S3.

As of May 2025, Notion supports file uploads via API. The File Upload API supports direct upload for files up to 20 MB, multi-part upload for larger files, and indirect import from a public URL — specifically aimed at migration workflows. Paid workspaces can upload files up to 5 GB. Files must be attached to a page or block within 1 hour of upload, or they expire. (developers.notion.com)

This eliminates the need for S3 if your migration script uses the new endpoint. Most existing open-source tools have not yet integrated this API. You will likely need to fork the tool or write a custom wrapper.

Other open-source options

quip-export (by sonnenkern) is a Node.js tool that uses the Quip Automation API to export all documents and folders to your local filesystem in HTML or DOCX format — with optional embedded images and comments. It does not write to Notion directly, but it gives you a clean local archive that you can then script into Notion via the API.

npx quip-export -t "QUIP_TOKEN" -d ./output --embedded-images --comments

Note: the --comments and --embedded-images flags do not work together with --docx export.

The Notion Markdown API shortcut

Notion's API version 2026-03-11 introduced a markdown parameter for the Create Page endpoint. Instead of converting HTML into Notion block JSON, you can POST raw Markdown content directly:

curl -X POST https://api.notion.com/v1/pages \
  -H 'Authorization: Bearer '"$NOTION_API_KEY"'' \
  -H "Content-Type: application/json" \
  -H "Notion-Version: 2026-03-11" \
  --data '{
    "parent": { "page_id": "YOUR_PAGE_ID" },
    "markdown": "# Document Title\n\nYour content here."
  }'

This simplifies migration scripts significantly for basic content. Export from Quip, convert to Markdown if needed, push to Notion — no block-level JSON conversion required. The markdown parameter is mutually exclusive with children, so you cannot mix approaches in a single request.

However, the Markdown parameter has known limitations for complex content. Tables, code blocks with syntax highlighting, and deeply nested lists do not always convert reliably. If your Quip workspace contains a lot of these content types, test the Markdown path on representative samples before committing to it at scale. For complex documents, block-level JSON conversion gives you more control and more predictable output.

The same block limits apply on the Notion side. Very large pages (20,000+ blocks) may be truncated, with overflow blocks returned as <unknown> tags that require extra fetches.

Notion's behavior for duplicate page names

Notion does not enforce unique page titles. If multiple Quip threads share the same name — which is common in large workspaces with templated documents — Notion will create multiple pages with identical titles without warning. This creates silent confusion when navigating or linking. Build a naming convention into your migration script (appending the Quip thread ID as a suffix, for example) and clean it up post-import rather than discovering the collision after go-live.

The full API pipeline

A sane API migration usually follows this sequence:

List Quip threads
→ export HTML or spreadsheet data
→ download blobs and attachments
→ stage assets at stable URLs or upload directly
→ create Notion pages and databases
→ append blocks in chunks
→ rewrite internal links using an old→new ID map
→ run QA on formatting, attachments, and permissions

This is not overengineering. It is the minimum viable pipeline when both platforms enforce request and file limits that punish naive scripts.

What Breaks During a Quip to Notion Migration

Every migration path — manual, scripted, or assisted — encounters these failure modes. The difference is whether you plan for them or discover them after go-live.

Internal links

Quip documents link to each other via https://quip.com/<thread_id> URLs. These links are meaningless in Notion. In a manual migration, they remain as dead links. In a scripted migration, you need a link rewriting pass: build a mapping table of Quip thread IDs → Notion page IDs, then run a second pass to update every cross-reference. Most open-source tools do not do this.

Inline comments and chat history

Quip has three distinct types of comment-like content that need to be understood separately before you can make product-level decisions about them:

• Inline annotations are tied to specific section_id values within a thread. They function like margin comments on a specific paragraph.
• Thread messages are the conversation pane associated with the document as a whole — visible in the right-hand sidebar.
• Page-level context in Notion maps to block-level or page-level comments, which are structurally different from both of the above.

The critical constraint: section_id values do not survive HTML export. Once a Quip document is exported to HTML, the section anchors that inline annotations reference are gone. This means annotation recovery after export is structurally impossible — not just difficult. If you need inline annotation history, you must extract it via the Quip Automation API before exporting the document, and stage it separately.

The Automation API's Get Recent Messages endpoint returns only the 25 most recent comments per thread. Retrieving the full comment history requires pagination across all comment types — and thread messages and inline annotations are returned through different endpoints.

Notion's public API supports page-level and block-level comments, but it cannot recreate Quip's per-section inline annotation model exactly. The transformation is lossy regardless of method.

If your team uses Quip for architectural decision records (ADRs) or contract redlining, that historical context is at risk. The honest answer: you need product-level decisions. Flatten comments into page comments? Store them in an audit appendix? Keep Quip read-only for a review window? There is no field mapping that makes inline review history perfect.

Embedded spreadsheets

A Quip document can contain multiple embedded spreadsheets, each with formulas (400+ functions), cell-level comments, and formatting. When exported:

• HTML export: renders as an HTML table — flat data, no formulas.
• XLSX export: preserves formulas and data, but produces a standalone file disconnected from the document.
• API extraction: returns the spreadsheet as structured JSON sections, but converting Quip's section-based cell model to Notion's column-property model requires custom mapping.

Notion databases support formulas, but Quip and Notion formula languages are completely different. There is no automated converter. Every formula must be manually rewritten. Quip allows up to 100,000 cells per spreadsheet, so row-by-row transformations at scale get slow and fragile. (desktop.quip.com)

For table-heavy workspaces, the practical path is: export Quip spreadsheet data as CSV, import into a Notion database, then rebuild relations, rollups, and formulas after import.

Attachments and images

Quip stores images as blobs identified by blob_id within each thread. To extract an image via API, call the Get Blob endpoint with the thread ID and blob ID.

The trap: Quip's HTML export may include base64-encoded images or references to Quip's CDN, but those CDN URLs are authenticated. Once your Quip subscription ends, they are gone. Always download and re-host images before your Quip access expires.

On the Notion side, Free workspaces cap uploads at 5 MB per file; paid workspaces allow up to 5 GB. API uploads over 20 MB require multi-part upload. If your Quip docs contain many files, treat attachment migration as a separate workstream, not a side effect of document import. (developers.notion.com)

Folder hierarchy

Because Quip folders behave like tags, a single thread can live in multiple folders. Notion pages live in exactly one location in the page tree. During migration, you need a canonical parent rule. Common choices: first-seen path, authoritative team folder, or duplication plus backlinks. Our advice: do not duplicate by default. Pick one canonical location and create reference pages or backlinks elsewhere.

Live apps, polls, and Salesforce embeds

Notion explicitly excludes Quip live apps and polls from self-serve import. Coda's native importer documents the same limitation — most live apps cannot be recreated because Quip does not export the underlying data. If your workspace relies on project trackers, calendars, Kanban boards, or Salesforce embeds, plan a rebuild in Notion using databases, views, and automations — not an import. (notion.com)

Permissions

Quip supports document-level sharing with granular roles (full access, edit, comment, view). Notion's permission model operates at the workspace level and the page level, and it does not read or inherit anything from Quip's sharing settings.

When pages are created via the Notion API, they inherit the default workspace permissions of the integration that created them — not the per-document sharing rules from Quip. This means documents that were intentionally restricted in Quip may become broadly accessible in Notion unless you explicitly reconfigure page permissions post-import.

For teams with sensitive documents — legal, HR, finance, executive — permission migration should be a planned workstream, not an afterthought. Audit your Quip sharing settings before you migrate, decide on a Notion permission structure, and apply it page by page after import. There is no automated path.

Migration Method Comparison

The Migration Plan We Recommend

Regardless of which method you choose, follow this sequence.

1. Inventory the workspace before exporting anything

Separate content into four buckets: standard docs, spreadsheet-like content, attachments, and Quip-only features (live apps, polls). Mark any document that appears in multiple folders — that single step saves hierarchy pain later. Also audit document-level sharing settings in Quip now, before you lose access to them.

2. Export a full backup

Use the Admin Bulk Export API (36,000 docs/hour) to create a safety-net archive. The API produces PDF, DOCX, and XLSX output. For archival purposes, DOCX is the most portable format for prose documents and XLSX is the most useful for spreadsheet-heavy content. Store it somewhere durable. This is insurance, not your migration source.

3. Decide the target model in Notion first

Not every Quip page should become a Notion page. Some should become databases:

• Narrative docs → Notion pages
• Repeatable records → Notion databases
• Attached files → Notion file blocks or Files & media properties
• Live apps → rebuilt workflows, not imported artifacts

4. Run a pilot with representative content

Test 10–20 items that include at least one ugly table, one attachment-heavy page, one cross-linked page, and one spreadsheet. Measure import fidelity and operator time. If the pilot already needs hand fixes you cannot tolerate at scale, do not bet the full migration on more manual work.

5. Split document migration from spreadsheet migration

Handle Quip docs via HTML or Markdown. Handle spreadsheet data via CSV into Notion databases. Rebuild relations, rollups, formulas, and views after import. This is slower upfront but cleaner than pretending a Quip spreadsheet and a Notion database are the same thing.

6. Import in controlled batches

Small batches make failures debuggable. Notion warns that very large ZIPs and repeated imports can fail or partially import. If you are scripting, respect both Quip and Notion rate limits from day one instead of adding backoff after the first timeout storm.

7. Rewrite internal links

Build a mapping table of Quip thread IDs → Notion page IDs. Run a second pass across all migrated pages to replace quip.com URLs with Notion page links. This step is critical for maintaining wiki-style cross-references.

8. Run a real QA pass before cutover

Check these items:

• Page count vs. source count
• Missing attachments and broken images
• Internal links and anchors
• Table layout and database property mapping
• Comment handling outcome
• Page permissions vs. original Quip sharing settings

The worst outcome is discovering the complexity after your Quip site goes read-only. Start now.

For Notion-side QA quirks, our guide to fixing Notion export errors is a useful companion.

Where ClonePartner Fits

If you have a handful of clean pages, do it yourself. You do not need a service provider for ten simple docs.

If you have multi-folder docs, spreadsheet-to-database mapping, attachment-heavy pages, or a deadline that rules out weeks of manual QA, an engineer-run migration makes more sense. We treat Quip-to-Notion as three separate jobs: extraction from Quip with rate limit management, transformation into a clean Notion model with link rewriting and hierarchy mapping, and post-import QA for links, files, and structure.

We handle image and file transfers directly — no intermediate AWS S3 buckets. We map every Quip thread ID to its new Notion Page ID so internal links resolve correctly. We manage the throttling across both APIs so your migration runs without timing out or skipping pages. And we make product-level decisions about comments, formulas, hierarchy, and permissions with you — not for you.