Quip Data Deletion Clock: Timelines, API Limits & Migration Phases

Quip Data Deletion Clock: Timelines, API Limits & Migration Phases

Once your Quip subscription expires, you get exactly 90 days of read-only access, then 30 days of blocked logins, then roughly 30 days of data deletion. That is approximately 150 days from subscription end to permanent data loss — and the only window where you can still extract data via the API is the first 90. If your migration is not finished before blocked logins begin, you are locked out. If you have not started before read-only begins, you have already lost the ability to clean your source data.

This guide covers the exact operational constraints of each shutdown phase, what happens to the Quip Automation API during the read-only window, and why your extraction work must be completed before your contract term ends.

The Official Quip Retirement Timeline

Salesforce published the Quip retirement notice on March 3, 2026 (last updated July 29, 2026). Here are the dates and phases sourced directly from the official article:

• February 17, 2026: New paid, free, and trial Quip accounts are no longer available to users who are not existing customers.
• March 1, 2027: Final date for Quip subscription renewals. After this, no customer — enterprise or self-serve — can extend their contract.
• March 31, 2027: Free users (no paid contract) lose all access.
• Post-expiration Phase 1 — Read-Only (90 days): The site enters read-only mode immediately. Users can log in but cannot collaborate.
• Post-expiration Phase 2 — Blocked Logins (30 days): After the read-only phase, users can no longer log into the Quip site.
• Post-expiration Phase 3 — Data Deletion (~30 days): After the blocked-login phase, the deletion process begins and typically takes around 30 days to complete.

Salesforce has confirmed that Quip content will not be automatically moved on your behalf.

Your deadline is not March 2027

The March 1, 2027 date is the renewal cutoff — not the shutdown date. Your real deadline is your subscription term-end date, which could be months earlier. An enterprise customer whose contract ends in November 2026 enters read-only in November 2026. The public retirement date is irrelevant to their extraction timeline.

Confirm your term-end date with your Salesforce account team or check your Stripe billing if you are a self-serve customer.

What Each Phase Means for a Migration in Progress

Not all 150 days are equal. Each phase eliminates capabilities that specific migration tasks depend on.

Active subscription (before expiration)

The active subscription phase is the only period where you have full read-write access to your Quip instance through both the UI and the API. This is when all meaningful migration preparation must happen.

What works:

• Full Quip UI editing, sharing, and collaboration
• Automation API read endpoints (GET /1/threads/{id}, GET /1/folders/{id})
• Automation API write endpoints (POST /1/threads/edit-document, POST /1/threads/new-document)
• Admin API with both ADMIN_READ and ADMIN_WRITE scopes
• Bulk Export API (up to 36,000 documents per hour per company)
• User and permission management via the Admin Console

What you should be doing:

• Inventorying all documents, folders, and ownership
• Cleaning up permissions and resolving orphaned document owners
• Renaming documents with non-descriptive or illegal titles
• Standardizing folder structures and flattening deep hierarchies
• Running test extractions to benchmark API throughput
• Completing a full trial migration to your destination platform

Read-only phase (90 days post-expiration)

The read-only phase begins the moment your subscription expires. Users can still log in and view every document, but all editing, collaboration, and content creation stops — in both the UI and the API.

What still works:

• Logging in and viewing documents
• API read endpoints (GET requests return HTTP 200)
• Bulk Export API (read-only export operations)
• Downloading individual documents via the UI

What fails:

• POST /1/threads/edit-document — blocked. You cannot modify text, update tables, or change titles.
• POST /1/threads/new-document — blocked. No new document creation.
• POST /1/messages/new — blocked. You cannot add comments or migration audit logs.
• POST /1/folders/add-thread — blocked. You cannot move documents between folders.
• DELETE /1/threads/{thread_id} — blocked.
• Admin write operations (ADMIN_WRITE scope) fail.

The specific HTTP status code returned by Quip for write attempts during read-only mode is not formally documented in Salesforce's public API reference. Community reports and developer forum threads indicate a 4xx response (most commonly 403), but treat any write attempt during this phase as unsupported regardless of the exact status code returned. Build your extraction scripts to attempt only GET requests and treat any non-2xx response on a write endpoint as a hard stop.

What this means for migration: You can still extract data, but you cannot fix anything. If a document has the wrong owner, a misleading title, or broken folder placement, you are exporting it as-is. Every data quality issue you did not resolve during the active phase becomes a cleanup problem in the destination.

If your migration playbook relies on tagging documents as "Migrated" or moving them to an archive folder after extraction, that workflow breaks the moment your subscription expires.

Blocked-login phase (30 days after read-only ends)

The blocked-login phase begins after the 90-day read-only window. During this phase, neither the Quip UI nor the API is accessible. Logins are blocked entirely. Your data exists on Salesforce's infrastructure, but you cannot reach it through any supported channel.

There is no support ticket, no escalation path, and no emergency access that will retrieve your data during this phase. API tokens that functioned during read-only return authentication errors.

Data deletion (~30 days after blocked logins end)

The data deletion phase starts after the blocked-login period. Salesforce has stated the deletion process typically takes around 30 days to complete. After that, the data is permanently gone. There is no recovery mechanism, no archive, and no rollback.

Why Extraction Must Start Before Read-Only

The most common mistake in Quip migration planning is treating the read-only phase as the start of the project. It is not. Read-only is the emergency-extraction window. The real work — the work that determines whether your migration is clean or chaotic — requires write access to the source.

Resolving document ownership

Quip documents are owned by individual users. When someone leaves the company, their documents may become orphaned — still accessible but owned by a deactivated account. Reassigning ownership requires write access to the Admin Console or the Admin API's ADMIN_WRITE scope.

During read-only, you cannot reassign ownership. You will export documents attributed to email addresses that no longer exist in your organization, and your destination platform will have no valid owner to map them to. Salesforce notes that private-folder transfer only works after the source user has been deactivated, the transfer can take up to a few hours, and if the only user with Full Access on a document has left the organization, Salesforce support may be required. (help.salesforce.com)

Cleaning up permissions

Quip's permission model is folder-and-user-based, not role-based. Documents shared with external collaborators, personal folders mixed with team content, and inconsistent access levels are common. Moving a document can change membership based on folder access, but users added individually retain access even after a move. Disabling a shared link does not remove people who already joined as collaborators. (help.salesforce.com)

Fixing permissions before extraction means your export reflects the intended access structure. Fixing them after extraction means manually re-permissioning hundreds or thousands of documents in the destination.

Renaming files and flattening folder structures

Quip allows document titles containing characters that destination systems forbid. SharePoint and OneDrive reject file names containing ", *, :, <, >, ?, /, \, and |. Standard practice is to run a sanitization script against the source to rename these documents before export, preserving internal links between documents that rely on titles or thread IDs.

Quip also allows deeply nested folder hierarchies that can exceed path-length limits on destination systems (SharePoint enforces a 400-character URL limit). Engineers must flatten these structures before the final export. Both renaming and folder restructuring require write access. During read-only, the source is locked.

Running test migrations with round-trip validation

A proper migration workflow extracts content, loads it into the destination, validates it, finds problems, fixes the source, and re-extracts. That feedback loop requires write access. During read-only, you can extract and load, but you cannot fix and re-extract. Every problem you find becomes a manual patch in the destination.

Performing a controlled content freeze

Before final extraction, you need a content freeze — a defined point where no new documents are being created and no existing documents are being modified. Enforcing this via admin controls requires ADMIN_WRITE access. If you wait until the platform forces read-only on you, you have not controlled the freeze — you have been caught by it, with no visibility into what changed in the final hours before expiration.

Handling incremental and delta extractions

Quip thread objects include a updated_usec timestamp (microseconds since Unix epoch) on the thread-level response from GET /1/threads/{id}. This allows incremental pulls: record the timestamp of your last full extraction, then filter subsequent calls to threads modified after that point. However, Quip has no native webhook or change-feed API — delta detection requires polling, and polling at scale consumes rate-limit budget. Plan your delta-sync pass as a final step during the active subscription phase, not during read-only, where write access to fix newly discovered issues is already gone.

Technical Constraints That Make the Last 90 Days Worse Than You Think

Even if you only need to read data during the read-only phase, the Quip API imposes hard throughput constraints that stretch extraction timelines.

Rate limits and parallel extraction behavior

The Automation API is capped at 50 requests per minute per user and 600 requests per minute per company across all users and integrations. The Admin API allows 100 requests per minute per user with the same 600-per-minute company ceiling. The Bulk Export API supports up to 36,000 documents per hour per company, but bulk export only covers raw document content — comment threads, folder metadata, and permission mappings require separate calls through the Automation or Admin APIs. (help.salesforce.com)

The per-user and per-company limits interact in a non-obvious way. If you run 13 extraction scripts in parallel, each authenticated as a different user at 50 req/min, your aggregate rate is 650 req/min — above the 600 req/min company ceiling. The company ceiling is the binding constraint regardless of how many users are under their individual limits. All scripts share the same ceiling and will collide, triggering rate-limit responses across all of them simultaneously. The optimal parallel extraction strategy is to keep total concurrent request throughput under 600 req/min and distribute calls evenly across authenticated users to avoid any single token exhausting its per-user limit first.

If you have 500,000 documents, a simple GET loop through the Automation API takes roughly 14 hours just to read metadata — ignoring network latency, backoff time, and retries.

One technical detail: Quip may return HTTP 503 for rate-limit responses rather than the standard 429 Too Many Requests. Standard retry logic will misclassify 503 as a server error and apply a different (often shorter) backoff than intended. Build your scripts to treat both 503 and 429 as rate-limit signals and apply the same exponential backoff to each.

Large thread and pagination behavior

Quip threads with very long message histories (thousands of messages) or large embedded spreadsheets may exhibit different behavior at the API level. The GET /1/threads/{id} endpoint returns the full thread object in a single response — there is no documented pagination parameter for message lists within a thread. For extremely large threads, this can produce response payloads that exceed practical memory limits for in-process parsing. If you are working with threads that contain thousands of inline messages, test your extraction scripts against the largest threads in your instance before the read-only window begins. A thread that times out or causes a memory fault during read-only cannot be restructured to be smaller.

Export format limitations

Quip has no native feature that exports all company data into a single ZIP preserving the site's folder structure. API export formats can show minor formatting variations compared with the live application. Conversation history in the async bulk export is supported only for DOCX and XLSX formats.

For spreadsheet-heavy sites: PDF export can take up to 10 minutes for large threads, caps spreadsheet export at 40,000 cells, and excludes charts. Generated PDF URLs expire after 72 hours, so delayed collection jobs can miss their download window. Salesforce recommends breaking large exports into batches of about 5,000 documents at a time, and the Admin Console's JSON export may not be available for companies with a large amount of data. (help.salesforce.com)

What a Bulk Export ZIP actually contains. The async bulk export produces a ZIP archive where each document is represented as a file named using the thread ID (not the document title), in the format requested (DOCX, XLSX, PDF, or HTML). The ZIP does not replicate the source folder hierarchy — documents from nested folders are placed at a flat level. A separate metadata file (JSON) maps thread IDs to document titles, folder paths, and owner information. If you rely solely on the ZIP for migration, you must join the metadata file to the document files using thread ID to reconstruct folder placement and ownership. Plan for this join step in your transformation pipeline.

API setup is not instant

Salesforce's bulk-export guidance requires: granting an admin role that includes Unredacted Audit Access to All Members & Content, creating an API key, obtaining a token, and retrieving all thread IDs before any export can begin. If you are exporting by folder, you must traverse nested child folders to find all contained threads. (help.salesforce.com) None of this setup is instant, and doing it for the first time under a 90-day deadline is risky.

For a deeper look at extraction methods, see our Quip export guide.

How to Audit Your Quip Instance Before Expiration

Before you can plan a migration timeline, you need exact counts of documents, folders, and orphaned files. Use the Quip Automation API to run a pre-migration audit months before your contract expires.

import requests
import time
 
QUIP_API_BASE = "https://platform.quip.com/1"
TOKEN = "YOUR_ADMIN_TOKEN"
HEADERS = {"Authorization": f"Bearer {TOKEN}"}
 
def get_current_user():
    response = requests.get(f"{QUIP_API_BASE}/users/current", headers=HEADERS)
    response.raise_for_status()
    return response.json()
 
def audit_folder(folder_id, depth=0):
    # Respect Quip API rate limits: 600 req/min per company ceiling
    # At 0.1s sleep, max throughput per script = ~600 req/min
    # Reduce sleep if running multiple parallel scripts to stay under company ceiling
    time.sleep(0.1)
    
    response = requests.get(f"{QUIP_API_BASE}/folders/{folder_id}", headers=HEADERS)
    # Quip may return 503 (not 429) for rate-limit responses — handle both
    if response.status_code in (429, 503):
        print("Rate limit hit. Backing off 10 seconds...")
        time.sleep(10)
        return audit_folder(folder_id, depth)
        
    data = response.json()
    folder_info = data.get("folder", {})
    children = data.get("children", [])
    
    print(f"{'  ' * depth}Folder: {folder_info.get('title')} ({len(children)} items)")
    
    for child in children:
        if "folder_id" in child:
            audit_folder(child["folder_id"], depth + 1)
 
# Initiate audit from the company shared folder
user_data = get_current_user()
company_folder = user_data.get("shared_folder_id")
audit_folder(company_folder)

This script maps the shared folder hierarchy. You must run similar audits against the private folders of all active and deactivated users to identify documents requiring ownership reassignment. Cache results in a local database to avoid redundant API calls. Note that the shared_folder_id returned by GET /1/users/current covers company-wide shared content; personal and starred folders require separate traversal using the private_folder_id and starred_folder_id fields on the user object.

Working Backwards: A Realistic Migration Timeline

For a typical enterprise Quip instance with 5,000–50,000 documents, a well-planned migration takes 6–12 weeks of active work. That is not elapsed calendar time — that is the time your team or migration partner is actively inventorying, scripting, extracting, transforming, loading, and validating. The calendar lead time you need is at least five months before your subscription expires.

Start from your subscription end date and work backwards. Here is what that looks like for a team with a contract ending on March 1, 2027 (the latest possible date for any renewing customer):

Teams that start in January 2027 for a March 2027 expiration are attempting to compress five months of work into eight weeks with no margin for the unexpected. If you are reading this and your contract expires in three months, you are already behind.

What If You Are Already in Read-Only?

If your subscription has already expired and you are in the 90-day read-only window, you are in emergency-extraction mode. Prioritize in this order:

1. Export everything first, organize later. Use the Bulk Export API to pull all documents as DOCX. This gives you a baseline archive even if the structured migration fails.
2. Extract metadata separately. Folder structures, document ownership, and permission data all come from the API. Export this into JSON or CSV alongside the document content. Use the thread ID as the join key to map documents to their metadata from the bulk export ZIP.
3. Do not attempt write operations. Write endpoints are blocked. Every call should be a read. Prioritize breadth — get all documents out before going back for comments and thread history.
4. Watch your rate limits and parallel script behavior carefully. At 50 requests per minute per user, extracting 10,000 documents with metadata takes roughly 3.3 hours of continuous, perfectly paced calls — assuming zero retries and no backoff. If running multiple scripts, keep total throughput under 600 req/min to avoid hitting the company ceiling.
5. Handle both 429 and 503 as rate-limit signals. Apply exponential backoff to both. Do not treat 503 as a transient server error — it may be Quip's rate-limit response.
6. Set a hard internal deadline at day 75. Give yourself a 15-day buffer for retries and validation before blocked logins cut off all access.
7. Use the Admin Export API if available. It provides bulk ZIP files instead of requiring individual GET requests for every thread, significantly reducing the number of API calls. Note the ZIP's flat structure — use the accompanying metadata JSON to reconstruct folder hierarchy.

Edge Cases and Failure Modes

Salesforce Live Apps and Data Mentions. Quip documents containing embedded Salesforce records (Live Apps) or Data Mentions reference live CRM data. When you export these documents, the references break — the Bulk Export API renders Data Mentions as blank or static text in some formats. Salesforce has already retired several low-usage and third-party Quip Live Apps and recommends exporting affected documents as PDF to preserve the current state, with the caveat that the PDF is a static snapshot and will not refresh external data. (help.salesforce.com)

Quip for Salesforce (embedded Quip). Customers using Quip embedded inside Salesforce CRM — as opposed to standalone Quip — face a partially different timeline and a different migration path. Quip for Salesforce surfaces Quip documents directly in Salesforce records. When Quip retires, these embedded document panels will stop functioning regardless of when the CRM customer's Quip subscription expires. If your organization uses Quip templates attached to Salesforce objects (Opportunities, Cases, etc.), those templates and their associated documents need to be migrated separately from the general Quip document corpus. Consult your Salesforce AE for specifics on the Quip for Salesforce retirement sequence, as it may differ from the standalone retirement timeline.

Documents shared with external users. Quip allows sharing with users outside your organization. During read-only, external users can still log in and view shared content but cannot edit. If external collaborators need copies of shared documents, they must export during the read-only window or lose access when blocked logins begin.

Thread-based architecture and message history. Quip treats documents and messages as a unified "thread." Comment threads, inline discussions, and chat history are part of the thread object, not separate entities. A document export that does not include the thread's message history loses the full collaboration context. The GET /1/threads/{id} endpoint returns both the document HTML and the message list, but for threads with thousands of messages, the full payload can be very large — and there is no documented pagination for the message list within a single thread response. Test your largest threads during the active subscription phase. A thread that causes memory or timeout issues during read-only cannot be split or restructured.

Free user cutoff. Free users — those on team sites or personal accounts with no paid subscription — lose access on March 31, 2027 regardless of other timelines. The official FAQ does not describe a read-only phase for free users, and their API behavior at cutoff is not documented. Access simply stops. (help.salesforce.com)

Choosing a Destination

This guide focuses on the timeline constraint, not the destination decision. The destination you choose affects how much pre-migration cleanup you need: moving to SharePoint requires restructuring Quip's flat thread model into a library-and-folder hierarchy, moving to Notion means mapping Quip's HTML to Notion's block-based format, and moving to Slack Canvases involves a conversion tool Salesforce released in July 2026 — but it only handles eligible documents and does not migrate spreadsheets or Live Apps.

For help choosing a target, see our guide for where to move documents after Quip retires or the Quip end-of-life playbook. If your target is Microsoft 365, our Quip to SharePoint migration guide covers extraction and mapping in detail.

The Clock You Actually Need to Manage

The Quip shutdown is not a single event — it is a sequence of closing doors. Each phase removes capabilities your migration depends on. The read-only phase is not a grace period; it is an extraction-only emergency window where you can pull data out but cannot fix anything. The blocked-login phase is only 30 days (not the 90 that some sources report), and during it you have zero access. After that, deletion is irreversible.

The constraint that matters most is source mutability. Once Quip stops accepting writes, you lose the ability to fix ownership, permissions, naming, and folder structure at the source. Every unfixed problem in the source becomes a manual remediation task in the destination — at a different scale, with a different toolset, and without the authoritative context that the source system provided.

Start your migration while you still have write access — that means starting months before your subscription expires, not weeks, and not after.