How to Export Data from Pipedrive: API Limits, Methods & Portability

How to Export Data from Pipedrive: API Limits, Methods & Portability

Pipedrive gives you four ways to get data out: the Export Data screen in settings (admin-only, full-entity CSV/Excel dumps), list view exports (filtered, column-customized), the REST API (programmatic, paginated), and webhooks (real-time, event-driven). Each method has different permission requirements, format constraints, and rate limits. This guide covers every extraction path, the token-based API budget you need to plan around, error handling for 429 responses, field serialization edge cases, and the gaps that trip up most teams during migrations and reporting projects.

The four Pipedrive export methods, compared

There is no single "export all" button in Pipedrive. You export each data type — deals, persons, organizations, activities, notes, files, leads, products — separately, using different tools depending on your goal.

How to export all data from Pipedrive using the UI

The Export Data feature is the fastest way to pull a complete dump of any single entity type. In the Export Data section, most item exports include default, custom, and system fields, along with ownership information and any linked records.

Step by step:

1. Go to Tools and apps → Export data
2. Select the data type (Deals, Persons, Organizations, Activities, Notes, Files, Leads, Products)
3. Choose CSV or Excel
4. Click Export
5. Download from the Generated exports list when the file appears

Only global admins and regular users with the correct permission set enabled can export data from the list or detail views. To use the Export Data option specifically, you need to be a full admin (both deals admin and global admin in Pipedrive's two-tier permission model — deals admin controls record-level access within pipelines, while global admin controls account-wide settings including exports).

List view export: filtered and column-specific

When you only need a subset — say, all lost deals from Q2 with specific custom fields — the list view export is the better tool.

Open a relevant list view and apply a filter to show the data you want to export. For example, select "All lost deals" to export only lost deals. Once your filter is applied, click the gear icon and choose which columns to include. In the deal list view, you can include deal, person, and organization fields in one export — the closest Pipedrive gets to a cross-object export without using the API.

Detail view export: single-deal XLSX

You can only export deal details as an XLSX file from the deal detail view. Open a deal and click "..." → Export as XLSX in the top right corner. The exported file includes deal details and any linked person or organization data. This is useful for one-off audits or stakeholder summaries, but not practical at scale.

What Pipedrive does NOT export (and how to get it)

This is where most teams get surprised during a migration. The default UI exports leave significant gaps:

• Files export as download links, not raw files. Files (PDFs, JPGs, attachments) appear in the CSV export as download URLs, not as the files themselves. Pipedrive does not support bulk raw file export. Each file must be downloaded individually via those links — and those links are authenticated and time-limited, which creates additional complexity if you're scripting bulk file downloads.
• Google Drive attachments are excluded entirely. Files stored via the Google Drive integration do not appear in any export.
• Activities, notes, and files linked to deals/contacts export separately. There is no combined export that pulls a deal plus all its linked records in one operation from the UI.
• No cross-object reporting in a single export. Pipedrive cannot natively combine deal, activity, and contact data in a single report. Each dimension must be exported separately and joined downstream.
• Email sync data is partially inaccessible. Emails synced into Pipedrive are visible in the UI, but raw email content is not included in standard exports. Extraction requires the Mail API endpoints (GET /api/v1/mailbox/mailMessages), and even then, email attachments require separate file download calls. Some metadata — headers, threading — may be incomplete depending on how the email was synced.
• Leads remain API v1-only. The Leads object has no v2 endpoint (as of March 2026). This has direct migration implications: leads cannot benefit from the 50% token cost reduction of v2, and any extraction script must handle leads through the v1 /leads endpoint with offset-based pagination. Fields accessible via the Leads API include title, owner, contact linkage, value, expected close date, and custom fields — but not all fields visible in the UI are exposed in the API response, so validate your field mapping before assuming completeness.

If you need a complete archive — deals with their associated activities, notes, files, and email threads all linked together — you'll need the API or a dedicated migration tool. The UI export was designed for spreadsheet-level reporting, not full-fidelity data portability.

Custom field serialization: what survives the export

Not all custom field types serialize cleanly in CSV or JSON. Understanding this prevents silent data loss:

The critical issue: API custom fields export as 40-character hex hash keys, not labels. When you pull deal data via the API, custom fields appear as a3b8d71ef209c4a4864b1afe9d8e5b23c12f0d87 rather than "Contract Value" or "Lead Source." Before extracting records, call the relevant fields endpoint to build a lookup table:

• GET /api/v2/dealFields → maps hash to label for deal custom fields
• GET /api/v2/personFields → for contact custom fields
• GET /api/v2/organizationFields → for organization custom fields

Enum and multi-option fields require an additional step: the field definition includes an options array mapping numeric IDs to label strings. Store that mapping before you process any records, or you'll export a dataset full of IDs that require a second pass to decode.

Pipedrive API extraction: endpoints, pagination, and authentication

The Pipedrive REST API is the only way to programmatically extract data with full control over field selection, filtering, and relational joins. It covers deals, contacts, organizations, leads, activities, products, pipelines, stages, notes, files, and the automation engine.

Authentication: API token vs. OAuth 2.0

Pipedrive supports two authentication methods: a personal API token and OAuth 2.0.

API tokens are static strings generated inside your Pipedrive account. An API token inherits the permissions of the user who generated it — if that user is not a global admin, the token cannot access admin-only endpoints. Critically, if the generating user is deactivated, the token is invalidated immediately. Any extraction script tied to a single user's token will break silently when that user leaves the company. For production pipelines, use a dedicated service account or OAuth.

OAuth 2.0 (Authorization Code flow) is required for multi-tenant apps or anything customer-facing. It issues scoped access tokens with refresh capability and does not tie authentication to a single user account.

The Lite tier at $14/month per seat includes full API access. A free developer sandbox account is available for building and testing integrations without touching production data.

Pagination: cursor-based vs. offset-based

Pipedrive supports two pagination styles, with a maximum of 500 items per page for both.

Cursor-based pagination (v2 endpoints) is the preferred approach for large datasets. It is the most efficient and stable method for traversing large entity collections. Unlike offset-based pagination, cursor-based pagination is stable under concurrent writes — inserting or deleting records while you're paginating does not cause records to be skipped or duplicated.

Offset-based pagination (v1 standard endpoints) uses start and limit parameters. It works but is less resilient: if records are created or deleted during iteration, your page offsets shift and you can silently miss or duplicate records. For any extraction where data may be changing in real time (live production accounts), cursor-based pagination is safer.

Here's a minimal Python example for cursor-based extraction with 429 handling:

import requests
import time
 
BASE_URL = "https://yourcompany.pipedrive.com/api/v2/deals"
API_TOKEN = "your_api_token"
 
def extract_all_deals():
    deals = []
    cursor = None
    while True:
        params = {"api_token": API_TOKEN, "limit": 500}
        if cursor:
            params["cursor"] = cursor
        
        resp = requests.get(BASE_URL, params=params)
        
        if resp.status_code == 429:
            # Pipedrive returns Retry-After header in seconds
            retry_after = int(resp.headers.get("Retry-After", 60))
            print(f"Rate limited. Waiting {retry_after}s before retry.")
            time.sleep(retry_after)
            continue  # retry same cursor position
        
        resp.raise_for_status()
        data = resp.json()
        deals.extend(data.get("data", []))
        cursor = data.get("additional_data", {}).get("next_cursor")
        if not cursor:
            break
    return deals

What are Pipedrive's API rate limits?

Pipedrive uses a token-based rate limiting (TBRL) system introduced in 2024, where each API request consumes tokens from a shared daily company budget. The daily budget formula is:

30,000 × plan multiplier × number of seats (+ purchased top-ups)

Token costs per operation

Not all requests cost the same. High-traffic sync workloads (Deals + Persons + Activities in parallel) burn through quota faster than naive request-count math implies.

Applied example: Extracting 50,000 deals at 500 per page = 100 GET list requests × 20 tokens = 2,000 tokens. Add 100,000 contacts (200 requests × 20 = 4,000 tokens), 200,000 activities (400 × 20 = 8,000 tokens), plus field definition lookups and note/file calls, and a full account extraction for a mid-size company might total 30,000–60,000 tokens — comfortably within a Lite plan's daily budget of 300,000 tokens (at 10 seats). The bottleneck for most extractions is not the daily budget but the burst rate.

Burst limits: the 2-second window

Burst rate limits apply per token on a rolling 2-second window:

The Search API is locked to 10 requests per 2 seconds across all plans regardless of auth method.

What happens when you hit rate limits

Burst limit exceeded (429): Pipedrive returns HTTP 429 with a Retry-After header specifying seconds to wait. The request is rejected — not queued. Your script must catch 429 responses, read the Retry-After value, sleep, and retry the same request from the same cursor position. Do not advance the cursor on a 429.

Daily token budget exhausted: When the daily budget is depleted, all subsequent requests return 429 until the budget resets. Pipedrive resets the daily token budget at midnight UTC regardless of your account timezone. If you're running an overnight migration that spans midnight UTC, plan for a brief interruption window. You can monitor remaining token budget via the X-RateLimit-Remaining response header.

Recommended backoff strategy: Start with the Retry-After value from the header. If no header is present, use exponential backoff starting at 2 seconds, doubling each retry, capped at 60 seconds, with a maximum of 5 retries before raising an exception. Log each 429 with the endpoint and cursor position so you can resume from a checkpoint rather than restarting the full extraction.

How to use Pipedrive webhooks for real-time data sync

Pipedrive webhooks push JSON payloads to a URL you specify whenever a tracked event occurs — a deal is created, a contact is updated, a note is added. Pipedrive allows up to 100 webhooks per company account, enabling you to monitor multiple events simultaneously.

Webhooks are the right tool for ongoing sync — keeping a data warehouse, helpdesk, or BI tool up to date in real time. They are the wrong tool for initial bulk extraction. Webhooks only report changes as they happen — they cannot backfill historical data. For initial population of a data warehouse or a CRM migration, use Pipedrive's paginated API endpoints or its built-in data export feature to get a complete snapshot first.

The standard architecture: Use the API for the initial full extract to establish a baseline. Then subscribe to webhooks for incremental updates going forward. This avoids polling the API continuously while ensuring you never miss an event.

Webhook reliability considerations: Pipedrive webhooks do not guarantee delivery ordering and will retry failed deliveries, but do not provide a dead-letter queue or guaranteed at-least-once delivery for all failure modes. If your webhook endpoint is down for an extended period, you may miss events. For high-reliability sync, combine webhooks with a periodic API reconciliation job (e.g., daily differential pull using update_time filters) to catch any gaps.

Pipedrive API v1 vs. v2: what you need to know now

Pipedrive is executing a gradual transition to API v2, which offers better performance, consistent REST behavior, stricter input validation, and 50% lower token costs. V2 endpoints are currently available for: Deals, Persons, Organizations, Activities, Products, Pipelines, Stages, Search, and Fields.

The Leads gap: Leads API remains v1-only as of March 2026, with no announced v2 endpoint. This matters for migrations because:

1. Leads extraction cannot use cursor-based pagination — you must use v1 offset-based pagination with its attendant risk of skipped records under concurrent writes
2. Leads extraction costs the full v1 token rate (no 50% reduction)
3. If your Pipedrive instance uses leads as a pre-deal qualification stage (common), and those leads haven't been converted to deals, they exist only in the Leads object — not in the Deals endpoint

The v1 deprecation deadline is July 31, 2026. Existing integrations using v1 modules will continue to run until that date. After July 31, 2026, v1 endpoints will no longer be available. If you're building new extraction scripts, build against v2 from the start. If you maintain existing v1 scripts, audit them now — the Leads endpoint will need a separate migration path once v2 support is announced.

Data portability and GDPR compliance

Pipedrive data portability means administrators can export all account data — contacts, deals, activities, notes, and email history — in standard CSV format at any time. Under GDPR, Pipedrive acts as a data processor.

GDPR rights Pipedrive can operationally support:

• Right of Access (SAR): Export records for the specific individual using the Pipedrive search to locate all linked entities (person record, deals, activities, notes, emails), then export each via API or detail view. Use GET /api/v2/persons/search?term={email} to locate the person record, then pull linked deals via GET /api/v2/deals?person_id={id}, activities via GET /api/v1/activities?user_id=..., and notes via GET /api/v1/notes?person_id={id}.
• Right to Erasure: Before deleting, export any records needed for legal retention (tax records, contract obligations). Delete the person record and confirm that linked deals are handled per your retention policy.
• Data Portability: Export in CSV (machine-readable) from the Export Data screen or via API in JSON.

All EU customers have a contractual relationship with Pipedrive's EU entity based in Estonia. Data is hosted in EU regions (Frankfurt, Stockholm, Dublin) or processed in GDPR-compliant regions.

Pipedrive maintains a comprehensive Audit Log (available on Advanced plans and above) that records every significant user action — logins, data exports, record deletions, permission changes, and integration events. This is useful for demonstrating chain of custody for exported personal data when responding to regulatory inquiries.

When to use each extraction method

One-time migration to a new CRM: Use the API for a full extract. The UI export works for simple cases, but preserving relationships between entities (deal → person → organization → activities → notes) requires the API. Extract in this order to build foreign keys correctly: (1) Users, (2) Organizations, (3) Persons, (4) Pipelines/Stages, (5) Deals, (6) Leads, (7) Activities, (8) Notes, (9) Files.

Weekly reporting to a spreadsheet: The list view export is the simplest path. Filter to the data you need, pick your columns, export. Verify no active filters are applied before exporting.

Real-time dashboard or warehouse sync: Combine an initial API extract with ongoing webhooks. Add a daily differential pull using update_time filters as a reconciliation layer against webhook delivery gaps.

GDPR data subject request: Use GET /api/v2/persons/search?term={email} to locate the individual. Pull all linked entities. Export. Delete after confirming the export is complete and retained per your legal hold policy.

Full backup for disaster recovery: Use the Export Data screen to pull each entity type as CSV. For automated backups, script the API extraction using cursor-based pagination, checkpoint each cursor position to a file, and store outputs in versioned cloud storage (S3 with versioning, GCS with object versioning). This lets you resume a failed backup without restarting from scratch.

Bulk file download: Files export as authenticated download links in the CSV. Those links are time-limited (verify expiry before scripting bulk downloads) and may be subject to the same API rate limits as other requests. Test with a small batch before scripting thousands of file downloads in parallel — aggressive concurrency will trigger 429 responses.

Common export pitfalls and how to avoid them

Custom fields export as hash keys, not labels. When you pull data via the API, custom fields appear as 40-character hex strings. Call the fields endpoint first and build a complete lookup table before processing records. Enum and multi-option fields require a second level of lookup: field hash → option ID → option label.

API tokens from deactivated users break silently. If the user who generated your extraction script's API token is deactivated, the token stops working immediately. Your script will receive 401 errors with no obvious explanation. Always tie production extraction tokens to a dedicated service account or use OAuth.

Email data is partially inaccessible. Raw email content is not in standard exports. Extract via Mail API endpoints. Attachments require separate download calls. Some sync methods (BCC dropbox vs. full email sync) result in different levels of data accessibility via the API.

Leads are silently absent from deal exports. Unconverted leads do not appear in the Deals export. If your team uses Leads as a qualification stage, you must export them separately via the Leads API — they are a distinct object, not a deal stage.

Duplicate records inflate export size. Pipedrive allows duplicate contacts and organizations. Accounts that have run for years without deduplication hygiene may contain high duplicate rates. Before importing into a target system, deduplicate on email address (persons), domain (organizations), and deal name + owner + close date (deals). Most target CRMs will create compounding duplicates if you import without cleaning first.

Making the right call on your Pipedrive export

Pipedrive's export tooling is solid for simple use cases — filtered CSV dumps, single-deal snapshots, chart exports from Insights. Where it breaks down is multi-entity extractions, file portability, and cross-object data preservation. The API fills most of those gaps, but you need to account for the token-based rate limits, the v1-to-v2 transition, the July 2026 v1 deprecation deadline, the Leads v1 gap, and the work of mapping 40-character custom field hashes through two levels of lookup (hash → field name, option ID → option label).

The extraction order matters: Users → Organizations → Persons → Pipelines/Stages → Deals → Leads → Activities → Notes → Files. Skip this sequence and you'll have foreign key references to entities that don't exist yet in your target system.

For straightforward reporting exports, the built-in tools work fine. For migrations, integrations, or anything that needs relational fidelity across deals, contacts, activities, and files — plan for the API, build checkpoint logic for 429 recovery, handle the Leads v1 separately, and clean duplicates before import.