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

API rate limits you will hit

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

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

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.

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's per-paragraph comments ("annotations") and the conversation pane (thread messages) are not included in any standard export format. The Automation API's Get Recent Messages endpoint returns only the 25 most recent comments per thread. Retrieving all comments requires pagination — and those comments are separate from inline annotations, which are tied to section IDs that do not survive HTML export.

Notion's public API can add page-level or block-level comments, but it cannot start a new inline discussion thread on page content. Mapping Quip's per-section inline comments to Notion's comment model is a lossy transformation. If your team uses Quip for architectural decision records (ADRs) or contract redlining, that historical context is at risk. (notion.com)

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)

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.

2. Export a full backup

Use the Admin Bulk Export API (36,000 docs/hour) to create a safety-net archive. 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

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, and hierarchy with you — not for you.

The practical difference between a demo migration and a production one is whether your wiki still works after the move.