Notion to Quip Migration: API Limits & Database Mapping

There is no native migration path from Notion to Quip. No importer, no connector, no drag-and-drop. Quip retired its Upload/Import feature in January 2024, and Notion exports databases as flat CSV files that strip out every relation, rollup, and formula. If you're planning to move a workspace of any meaningful size, you're looking at a multi-step API project with tight rate limits on both sides.

This guide covers the technical reality: what exports in what format, how to map Notion's block-based databases to Quip's document-spreadsheet hybrid, and where the API bottlenecks will stall your scripts.

Why a Notion to Quip Migration Is Harder Than It Looks

Two architectural problems make this migration difficult from the start.

Problem 1: Quip killed its import feature. The Upload/Import option in the Compose menu and the Import API endpoint were retired on January 19, 2024. You cannot upload a DOCX, CSV, or HTML file directly into Quip through the UI anymore. The only programmatic path left is the Automation API's new-document and edit-document endpoints, which accept raw HTML or Markdown content — one document at a time.

Problem 2: Notion's data model has no analog in Quip. Notion is block-based: every element — a paragraph, heading, image, toggle list, or database row — is an individual JSON block with a unique ID. Pages can nest infinitely inside other pages. Quip is thread-based: its core unit is a thread (a document, spreadsheet, or chat with an attached message history). Quip documents are broken down into smaller units called sections. Every paragraph in a document is a separate section, as is every item in a list or cell in a table. There's no concept of relational databases, nested pages, or block-level IDs that carry semantic meaning.

Quip folders are not traditional file system folders. Quip folders are more like tags, i.e., a thread can be in multiple folders. A Notion page tree cannot be mirrored literally in Quip. In practice, parent pages usually become folder tags, breadcrumb text, or index docs with links to child threads.

The result: every migration requires an extraction layer, a transformation layer, and a loading strategy — all custom-built.

Understanding Quip Import Formats and Notion Export Limits

Before writing any migration code, you need to know exactly what Notion gives you on export and what Quip can accept on the other side.

What Notion Exports

You can export all your pages as HTML, Markdown, or CSV (for databases), along with any files you've uploaded. Here's what that means in practice:

Any non-database Notion page can be exported as a Markdown file. Full page databases will be exported as a CSV file, with Markdown files for each subpage.

Relational links (IDs): Linked databases lose their human-readable connections and export as raw IDs. This is the single biggest data-loss risk in a Notion-to-Quip migration. If your Notion workspace relies on cross-database relations (e.g., linking a "Projects" database to a "Tasks" database), those links become meaningless strings in CSV.

Full workspace exports can be slow. Depending on your workspace size, it can take anywhere from a few minutes to several hours. Extremely large workspaces may occasionally experience timeouts or take up to 30 hours.

One export limit that matters in real projects: when exporting a Notion database, you can only choose the current view or the default view — not every view at once. If users rely on multiple filtered or grouped views, decide which ones you actually need to recreate in Quip and which should become separate sheets or index docs.

For a deeper breakdown of every Notion export method — including API-based extraction — see our complete guide to exporting Notion data.

What Quip Accepts via API

With the native import feature gone, the Quip Automation API's POST /1/threads/new-document endpoint is your primary entry point. The format parameter accepts either html or markdown. Defaults to html. The type parameter accepts either document, spreadsheet, or slides. Defaults to document.

Key constraints:

• Quip's create/edit document APIs cap content at 1 MB per request. Large Notion pages need chunking.
• For spreadsheets, the content must be wrapped in an HTML <table>. When more than one row is supplied, the first <tr> becomes the column header.
• Quip supports most Markdown tags, not all. HTML is the safer format for complex content.
• Folder assignment happens via the member_ids parameter on document creation.
• Sentence-level patching is not supported. To change a sentence, you replace the entire paragraph. For delta syncs, your unit of change should be a heading section or paragraph block, not arbitrary text fragments.

Your migration script must convert Notion Markdown/HTML to Quip-compatible HTML, strip unsupported block types (callouts, toggles, synced blocks, embeds), POST each document individually, and handle folder assignment programmatically.

Mapping Notion Databases to Quip Spreadsheets

This is where most migrations lose integrity. Notion databases are relational data stores with typed properties (select, multi-select, date, relation, rollup, formula). Quip spreadsheets are grid-based calculation tools embedded inside documents — closer to a lightweight Excel than a database.

Property Mapping Reference

Cell Limits and Sizing Math

The mapping challenges compound when you consider Quip's scale limits. Quip allows you to add a maximum of 100,000 cells to a spreadsheet. You can add a maximum of 1,000 rows with each API call. For best performance, it's recommended that you limit the number of cells you add to a maximum of 30,000 for each spreadsheet.

Do the math before cutover: rows × mapped columns = cell count. A Notion database with 20 columns and 5,000 rows = 100,000 cells — exactly at Quip's hard limit. A 12,000-row table with 12 mapped columns is 144,000 cells and must be split before load. If your database exceeds the limit, partition by business unit, date range, archive status, or some other stable dimension before you write anything.

For teams familiar with similar structural mapping problems, our guide on mapping Notion databases to SharePoint lists covers many of the same patterns — Quip introduces even more constraints because it lacks typed columns entirely.

Pre-Computing Relations Before Export

The most common workaround for relation data loss:

1. In Notion, create a formula column that outputs the related page's title as plain text (e.g., prop("Related Project").map(current.prop("Name")).join(", "))
2. Export the database — the formula column exports as static text in the CSV
3. Import that text into Quip as a regular cell value

You lose the live link, but you preserve the human-readable reference. Rollups need the same treatment: create a formula that outputs the rollup value as text, then export. Document the original relational structure in a separate mapping spreadsheet — you'll need it for post-migration validation.

HTML Table Format for Spreadsheet Creation

Quip's spreadsheet creation endpoint expects an HTML table. A plain CSV file is usually only an intermediate artifact, not the final payload:

<table>
  <tr>
    <td>legacy_notion_page_id</td>
    <td>Deal name</td>
    <td>Status</td>
    <td>owner_email</td>
    <td>related_account_ids</td>
    <td>renewal_rollup_snapshot</td>
  </tr>
  <tr>
    <td>notion:2f4d...</td>
    <td>Acme Renewal</td>
    <td>Open</td>
    <td>ae@example.com</td>
    <td>notion:abc123|notion:def456</td>
    <td>2026-06-30</td>
  </tr>
</table>

When multiple rows are supplied, the first row becomes the header. Keep a legacy_notion_page_id column in every target sheet — it's what lets you rebuild links, deduplicate retries, and run QA against source counts.

The API Bottleneck: Navigating Notion and Quip Rate Limits

Both APIs enforce aggressive rate limits. Running a naïve migration script against a workspace with 500+ documents will hit walls on both the read and write sides.

Notion API: 3 Requests Per Second

The rate limit for incoming requests per integration is an average of three requests per second. Some bursts beyond the average rate are allowed. Rate-limited requests will return a "rate_limited" error code (HTTP response status 429).

The practical impact is worse than it sounds. Because Notion's data model is so granular, API consumers are forced to make a high volume of requests just to read a single document. Reading a deeply nested Notion page requires recursive calls to GET /v1/blocks/{block_id}/children (max 100 children per response), checking has_children on every block, and recursing into each.

A page with 250 blocks, 50 toggles each containing 150 child blocks requires 103 separate API calls. At the strict rate limit of 3 requests per second, fetching this single page takes over 34 seconds.

Notion also warns that Search is not optimized for exhaustive workspace enumeration and that indexing is not immediate. If your discovery process relies on Search to find every page, your inventory can be incomplete before the migration starts. The sane pattern: start with a workspace export or known roots, then query shared databases directly using filter_properties to avoid pulling every rollup and formula on every request.

For your extraction scripts, implement:

• A request queue with strict concurrency control (not Promise.all() or unbounded threading)
• Exponential backoff with jitter on HTTP 429 responses
• Retry-After header parsing — Integrations should accommodate variable rate limits by handling HTTP 429 responses and respecting the Retry-After response header value, which is set as an integer number of seconds.

Quip API: 50 Requests Per Minute Per Token

The official docs note a limit of 50 requests per minute per access token for most endpoints. Quip's APIs are also subject to a per-company rate limit with a default of 600 requests per minute.

This is the tighter bottleneck. At 50 requests per minute per token, creating 500 Quip documents takes a minimum of 10 minutes — assuming one API call per document (which is optimistic; most documents need multiple calls for content chunking and folder assignment).

Real-world scripts confirm this is a persistent problem. One developer reported adding retry with multiplicative back-off up to about five minutes total, but the script still couldn't make it through. "Sometimes it gets in a state where it can't even start up, just 503: Over Rate Limit again and again on every request."

Third-party vendors flag the same issue: "Quip's Automation APIs have severely low Rate Limits and therefore you would need to contact your Quip Support to raise a ticket for upgrading the Rate Limit of the Service Account you created for us by at least 4X."

Your migration middleware must:

• Actively read Quip's X-Ratelimit-Remaining and X-Ratelimit-Reset headers
• Implement exponential backoff that treats HTTP 503 as a rate-limit response
• Queue payloads to ensure concurrent request limits are not breached
• Stay below the published ceilings, not on them — serialize writes per target thread and make every write idempotent so a retry cannot duplicate content

Combined Rate Limit Math

Here's the throughput ceiling for a Notion → Quip migration using a single token on each side:

The Quip write side is the bottleneck for documents. For spreadsheet data, the 1,000-rows-per-call batching helps — but you're still capped at 50 calls per minute.

DIY Scripts vs. iPaaS vs. Managed Migration

Three approaches exist. None is perfect.

Custom Scripts (Python + Both APIs)

Best for: Engineering teams with API experience and small-to-medium workspaces (< 200 docs).

You'll write a pipeline that crawls Notion via the API (recursive block traversal), converts blocks to Quip-compatible HTML, POSTs each document to Quip's new-document endpoint, assigns folders via member_ids, and handles rate limiting on both sides.

import time
import requests
 
QUIP_TOKEN = "your_quip_token"
QUIP_API = "https://platform.quip.com/1/threads/new-document"
 
def create_quip_doc(title, html_content, folder_id=None):
    payload = {
        "content": f"<h1>{title}</h1>{html_content}",
        "format": "html",
        "type": "document",
    }
    if folder_id:
        payload["member_ids"] = folder_id
    
    for attempt in range(5):
        resp = requests.post(
            QUIP_API,
            data=payload,
            headers={"Authorization": f"Bearer {QUIP_TOKEN}"}
        )
        if resp.status_code == 200:
            return resp.json()
        elif resp.status_code == 503:  # Quip rate limit — NOT 429
            wait = min(2 ** attempt * 2, 120)
            time.sleep(wait)
        else:
            resp.raise_for_status()
    raise Exception(f"Failed after 5 retries: {title}")

Trade-offs: You own every edge case. Toggle blocks, callouts, inline databases, code blocks with language tags, embedded images — each requires custom transformation logic. Maintenance burden is high, and a mid-migration failure requires idempotency logic to resume without duplicates. Access tokens expire every 30 days, so long-running projects need token refresh built into the runbook.

iPaaS (Zapier / Make)

Best for: Ongoing sync of new items only, not bulk historical migration.

For the integration with Quip, Zapier supports triggers like 'New Database Item', 'Updated Page', and 'New Comment' in Notion, enabling you to automate actions in Quip based on these events.

But the gaps are significant. You can't retrieve files and media attachments through the Zapier Notion integration. Accessing formulas within Notion databases isn't possible either. And relations — the big one — are not accessible.

Zapier operates one record at a time with its own rate limits, making it impractical for migrating hundreds of existing documents. Running 50,000 documents through Zapier will consume tens of thousands of premium tasks — often costing more in task overages than a dedicated migration service, with zero error handling for recursive block traversal.

For a broader look at CSV-based SaaS migration limitations, see our breakdown of using CSVs for SaaS data migrations.

Managed Migration (ClonePartner)

Best for: Workspaces with 200+ documents, complex databases, tight timelines, or teams that can't dedicate engineering cycles.

We handle the full pipeline: Notion API extraction with recursive block traversal, HTML transformation with formatting preservation, Quip API ingestion with custom backoff logic tuned for 503 handling, and spreadsheet creation within Quip's cell limits. We've built rate-limit-aware queuing systems for both APIs and handle the edge cases that break DIY scripts — nested toggles, inline databases, image re-uploads, and folder structure reconstruction.

We also don't pretend every move needs an outside partner. If your scope is a few hundred flat pages and no databases, doing it in-house is perfectly reasonable. If the move includes multiple related databases, attachments, custom formatting, a live Salesforce rollout, or a cutover window with no appetite for downtime, that's where an engineer-led migration service starts paying for itself.

See how we run migrations at ClonePartner for a detailed look at our process.

Pre-Migration Checklist: Preparing Your Workspace

Before writing a single line of migration code or engaging a migration partner, clean your Notion workspace. Garbage in, garbage out.

1. Audit Your Content

• Count pages and databases. Use the Notion API's search endpoint to enumerate all pages and databases — but don't rely on Search alone. Notion says Search is not guaranteed to return everything in a workspace. Start from known roots or a full workspace export.
• Identify nested page depth. Quip doesn't support deep nesting. Pages nested 3+ levels deep in Notion need to be flattened into a Quip folder structure.
• Flag unsupported block types. Synced blocks, template buttons, linked database views, and embeds have no Quip equivalent. Decide how to handle each: convert, drop, or log.
• Share every target database with the integration. Notion's Query a data source endpoint returns 404 if the parent database is not shared with your integration token.

2. Flatten Relations and Rollups

• Add formula columns to every database that resolve relation properties to plain-text names.
• Pre-compute rollup values into formula columns.
• Document the original relational structure in a mapping spreadsheet — you'll need it for post-migration validation.
• Do not promise users that Quip will keep Notion's live relational behavior without explicit rebuild work.

3. Clean Up Files and Attachments

• Download all attachments before migration. Notion file URLs expire hourly when accessed via API.
• Organize files by source page for re-upload to Quip (Quip requires separate blob upload via API).

4. Decide on Format and Add Stable IDs

• Pages → Quip documents: Export as HTML. Quip's HTML rendering is more predictable for complex content than Markdown.
• Databases → Quip spreadsheets: Export as CSV. Validate column counts against Quip's 100,000-cell limit per spreadsheet. Split large databases proactively.
• Add a stable legacy ID column to every database before export. This is what lets you rebuild links, deduplicate retries, and run QA against source counts.
• Pick a comments strategy up front. HTML export can include Notion comments; decide whether they will be archived, replayed selectively, or left behind.

5. Request Quip Rate Limit Increases

If your workspace is larger than ~200 documents, contact Quip Support before you start. If you need to call APIs more frequently than allowed by the Admin and Automation API rate limits, contact Quip Customer Support for help. This single step can cut your migration runtime by 50–75%.

6. Start Exports Early and Pilot with Ugly Data

• Start full-workspace exports early. They can take up to 30 hours to process.
• If you're unzipping exports on Windows, watch for path length issues. Notion's nested folder structure can exceed Windows' default 260-character path limit.
• Pilot with your worst data first — pages with child pages, files, callouts, long tables, and relation-heavy databases. Don't test on clean, simple pages and assume the rest will work.

Formatting That Breaks During Migration

Not everything survives the Notion → Quip journey. Budget time for post-migration QA, especially for customer-facing documentation.

Should You Migrate to Quip at All?

This is the question worth asking before you invest engineering time.

Salesforce has announced that all Quip products are being retired, and any subscriptions cannot be renewed after March 1, 2027. Quip will not be automatically moved. After subscription expiration: Read Only (90 Days) — the site is immediately put into read-only mode. Blocked Logins (90 Days) — users can no longer log into the Quip site. Data Deletion (~30 Days) — the data deletion process begins.

If you're migrating to Quip because of a Salesforce consolidation mandate, make sure your stakeholders understand the sunset timeline. You may be building infrastructure for a platform with a hard expiration date. Consider whether Slack canvases, Confluence, or another long-term platform would be a better migration target.

If you're already committed to Quip for the remaining subscription term, everything in this guide still applies — just plan for a second migration when Quip goes dark.

For teams evaluating alternatives, our Notion to Confluence migration guide covers a target platform with a longer runway.

Getting It Right on the First Pass

A Notion-to-Quip migration is not a copy-paste job. Between Quip's retired import feature, tight API rate limits on both platforms, and the fundamental mismatch between Notion's relational database model and Quip's flat document-spreadsheet approach, there's real engineering work required to move data without losing integrity.

The biggest risks:

• Data loss from unexported relations and rollups — flatten them before export
• Script failures from Quip's 503-based rate limiting — build retry logic that treats 503 as a rate limit, not a server error
• Exceeding Quip's 100K cell limit on large databases — split proactively
• Investing in a platform approaching EOL — make sure the timeline works for your organization

Successful migrations separate content from behavior. Content can be moved. Behavior — relations, rollups, views, search assumptions, and permission inheritance — has to be remodeled. Once you accept that, the project gets clearer: HTML for docs, API/CSV for data, stable IDs everywhere, throttled loads, and a delta pass before cutover.

If your workspace has more than a handful of documents and you need the migration done right the first time, that's exactly the kind of work we do.