How to Export Data from Richpanel: API Limits, Methods & Formats

What Data Can You Actually Export from Richpanel?

Richpanel is an e-commerce-native helpdesk built around Conversations (its ticket equivalent) linked to Orders synced from Shopify, BigCommerce, or WooCommerce. What you can extract depends on which method you use.

Method 1: Admin Panel CSV Export

Best for: Quick snapshots of conversation metadata, GDPR data subject requests, operational audits.

Not suitable for: Full data migration, preserving message threads, or extracting order-linked data.

Richpanel provides a built-in CSV export accessible from the inbox. You can export selected conversations or all conversations in the current view, with the file delivered by email. (updates.richpanel.com)

How to export conversations via CSV

1. Build the view you want. Use Richpanel's inbox filters and saved views to scope a date range, channel, or tag before exporting. (updates.richpanel.com)
2. Select conversations. Use bulk selection checkboxes to choose specific conversations, or operate on the entire current view.
3. Trigger the export. Use the bulk actions bar to initiate the CSV export.
4. Wait for the email. The export is delivered as a download link via email — it does not download instantly in-browser. (updates.richpanel.com)

CSV limitations

The CSV output is flat and limited:

• No message threads. You get conversation-level metadata (ticket ID, status, assignee, created date, resolution time) but not the actual message bodies.
• No internal notes or attachments. Agent notes and uploaded files are excluded entirely.
• Selection-based, not bulk. There is no "export all" button that dumps your entire conversation history into a single file. For accounts with thousands of conversations, this becomes impractical. (updates.richpanel.com)
• Broken order links. Richpanel embeds Shopify order IDs as relational links in conversation metadata. In a flat CSV, these become bare ID strings — the downstream system won't resolve the associated order history unless you rebuild the mapping against the source platform's order data.
• Undocumented schema. The public export documentation does not define the exact column schema, attachment treatment, or private-note coverage. Sample the output file before trusting it in a migration pipeline.

For anything beyond a quick audit, you need the API.

Method 2: REST API Extraction

The REST API is the primary extraction path for migration-grade exports. It's organized around key objects: Conversations (tickets with messages and metadata), Customers (profiles with contact and address data), Orders (purchase data linked to customers), Teams, Agents, Tags, and Channels.

Authentication and API access

Generate your API key from Settings → Integrations → API Keys in the Richpanel dashboard. Pass it in every request via the x-richpanel-key header:

curl -H "x-richpanel-key: YOUR_API_KEY" \
     "https://api.richpanel.com/v1/tickets/TICKET_ID"

Key endpoints for export

Edge case — response shape inconsistency: GET /v1/channels returns an object containing a channel array rather than a bare array. Other endpoints return bare arrays. Do not assume a uniform response envelope across endpoints — write defensive parsers that check the actual shape before iterating. (developer.richpanel.com)

Customer list gaps: The current customer docs show create/update and retrieval by email or phone, but do not prominently document a paginated list-all-customers endpoint. Customer custom field definitions are configured in People Data and are not available through the API — you can pull field values but not the field dictionary itself. (developer.richpanel.com)

Pagination

Richpanel uses offset pagination. Most list endpoints return a maximum of 100 records per page. Control page size with per_page (max 100) and navigate with page.

GET /v1/tickets?per_page=100&page=1

Responses include pagination metadata:

{
  "tickets": [...],
  "count": 15420,
  "next_page": "https://api.richpanel.com/v1/tickets?page=2",
  "previous_page": null
}

The two-pass extraction problem

This is where teams consistently underestimate the work. Listing conversations returns metadata — IDs, statuses, subjects, timestamps. To get full message threads, internal notes, and attachment URLs, you must fetch each conversation individually by ID.

Your extraction always requires at least two passes:

1. Pass 1: Paginate through all conversations to collect IDs and metadata.
2. Pass 2: Fetch each conversation by ID to get messages, notes, and attachments.

For 30K conversations at 100 per page: 300 list calls + 30,000 individual fetch calls = 30,300 API calls minimum. By comparison, Zendesk's Incremental Exports API returns full ticket objects including comments in a single paginated stream — no second pass required. Richpanel's two-pass requirement is a genuine architectural difference, not a documentation gap.

What the ticket detail endpoint gives you

GET /v1/tickets/{id} supports an include_private_notes flag and a show_visitor_profile toggle. The conversation object includes:

• Ordered comments array with body, plain_body, and html_body fields per message
• Public/private message state flag on each comment
• Attachment arrays within comments, containing file URLs and upload metadata
• cc_emails at the conversation level
• CSAT fields (rating, rating_comment)
• scenario_name and scenario_id for self-service portal context

Key nuance: Richpanel notes that conversation-number lookup has limited availability and may not work for imported conversations. Key your export on the conversation id field, not conversation_no. (developer.richpanel.com)

Diagnosing orphaned messages: If a conversation detail call returns a message_count field that does not match the length of the returned comments array, the fetch is incomplete — either due to a timeout or a partial response. Log this mismatch during extraction and queue those conversation IDs for a retry pass. Do not silently accept a short comments array as complete.

Multi-store accounts (appClientId)

If you operate multiple stores or brands, many endpoints require an appClientId parameter — a unique identifier for each store in your account. Find it in Settings → Connected Apps. You must run extraction per store; there's no cross-store bulk export.

Preserve appClientId and channel business_brand_id in your export manifest. Dropping store identity early makes later reconciliation significantly harder.

Method 3: Graph API Extraction

Richpanel also exposes a Graph API at https://graph.richpanel.com/data-api. API keys for this endpoint are generated from Settings → Advanced Settings → API Settings and passed via the x-richpanel-key header.

The Graph API returns conversation objects with fields like id, status, subject, type, email, rating, createdAt, and updatedAt. List queries accept first (page size) and offset parameters with a ConversationFilter for filtering.

API Rate Limits and Extraction Time Math

Rate limits are the binding constraint on any Richpanel data export. The two API surfaces document different limit models:

• REST API (developer.richpanel.com): 50 requests per 30 seconds. Returns HTTP 429 on breach, with Retry-After, X-RateLimit-Limit, and X-RateLimit-Remaining headers. (developer.richpanel.com)
• Graph API (api-doc.richpanel.com): 100 calls per minute. Returns HTTP 492 on breach — a non-standard status code specific to Richpanel's implementation, documented in their API reference. (api-doc.richpanel.com)

Both surfaces provide X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After headers. Normalized to a per-minute basis, both limits are equivalent: 100 requests per minute.

Extraction time estimates

These figures are calculated from the documented rate limits (100 RPM effective), assuming conversations only, single-threaded extraction, and no errors requiring retries. Actual elapsed time will be higher due to network latency, retry overhead, and attachment download time.

These numbers are conversation data only. For a 50K conversation account with 40K unique customers and 80K linked orders, budget for 170K+ total API calls — approximately 28 hours of extraction time at 100 RPM, before attachment downloads.

Rate limit handling in code

The code below handles both 429 and 492 explicitly, reads Retry-After from response headers, and inserts a conservative 0.6-second sleep between calls to stay safely under 100 RPM:

import requests
import time
 
API_KEY = "your_api_key"
BASE_URL = "https://api.richpanel.com/v1"
HEADERS = {"x-richpanel-key": API_KEY}
 
RETRYABLE_STATUS_CODES = {429, 492}  # 492 is Richpanel-specific rate limit code
 
def fetch_with_rate_limit(url):
    while True:
        response = requests.get(url, headers=HEADERS)
        if response.status_code in RETRYABLE_STATUS_CODES:
            retry_after = int(response.headers.get("Retry-After", 60))
            print(f"Rate limited ({response.status_code}). Retrying after {retry_after}s.")
            time.sleep(retry_after)
            continue
        response.raise_for_status()
        return response.json()
 
def extract_all_conversations():
    page = 1
    all_conversations = []
    while True:
        data = fetch_with_rate_limit(
            f"{BASE_URL}/tickets?per_page=100&page={page}"
        )
        tickets = data.get("tickets", [])
        if not tickets:
            break
        all_conversations.extend(tickets)
        page += 1
        time.sleep(0.6)  # Stay under 100 RPM
    return all_conversations
 
def fetch_conversation_detail(conversation_id):
    url = (
        f"{BASE_URL}/tickets/{conversation_id}"
        f"?include_private_notes=true&show_visitor_profile=true"
    )
    return fetch_with_rate_limit(url)

Extracting Core Data Objects

Conversations and messages

The Conversation (ticket) is the parent object. It holds status (Open, Resolved, Snoozed), the assigned agent, customer ID, and channel metadata. To get the actual transcript, you must fetch messages for each conversation using the detail endpoint.

Channel handling: Richpanel unifies chat, email, Facebook, Instagram, WhatsApp, and SMS into a single conversation model. The message format differs by channel: email messages use html_body, while live chat messages use plain_body. Your extraction script must handle both. If migrating to a system that only supports plain text, include an HTML-to-text parser (e.g., Python's html2text or BeautifulSoup) in your pipeline — do not strip tags manually, as this will corrupt formatted content.

Internal notes: Agent notes appear in the comments array with a private flag. When using include_private_notes=true, map these as private/internal notes in your target platform. Failing to do so exposes internal agent discussion to customers in the destination system.

Error pattern — orphaned messages: A completed detail fetch where len(response ["comments"]) < response ["message_count"] indicates a partial response. Log the conversation ID, the expected count, and the actual count, then queue it for a retry. This is the most common silent failure in high-volume Richpanel extractions.

Customers and e-commerce context

Customer profiles contain contact information and synced e-commerce data (lifetime value, order history links). The current docs show retrieval by email or phone but do not prominently document a paginated list-all endpoint. (developer.richpanel.com)

Customer custom field definitions are configured in People Data and are not available through the API. You can pull field values from individual customer objects, but reconstructing the full field dictionary (field names, types, allowed values) requires manual documentation before migration. (developer.richpanel.com)

Recommendation: Because Richpanel syncs commerce data from Shopify, BigCommerce, WooCommerce, Recharge, and similar platforms, export order and subscription data from the originating platform as well. Use the Richpanel export strictly for support history, and rely on native integrations in your target system to rebuild purchase context.

Attachments

Attachments (images, PDFs, videos) are not returned as raw file data. The API returns URLs within the comment objects in the conversation detail response. The storage backend for these URLs is not documented by Richpanel, and whether URLs have a fixed expiration period is not specified in the public docs. Treat all attachment URLs as potentially time-limited and download them immediately during extraction — do not defer to a second pipeline run.

The attachment extraction workflow:

1. Parse each comment in the conversation detail response for attachment arrays.
2. Extract the URL for each attachment object.
3. Issue an immediate GET request to download the binary file.
4. Save to your own permanent storage (S3, GCS, or local disk) with a filename that preserves the original conversation ID and attachment ID for traceability.
5. Rewrite the attachment URL in your exported JSON to point to your permanent storage location before loading into the target system.

Attachment downloads are additional HTTP calls. Test a sample of 50–100 attachments to determine whether downloads count against the API rate limit or bypass it as direct object-storage requests. If they count against the limit, factor download calls into your throughput budget.

E-commerce support frequently involves large files (product photos, defective-product videos). Set a minimum 120-second timeout and handle files up to 50MB without loading the full response body into memory — use streaming downloads.

Data That Does Not Export

Some Richpanel data is permanently non-portable. Know this before you start:

• Automation rules — Workflow triggers, conditions, and actions are configuration, not data. There is no documented API endpoint. Recreate them manually in your target platform. Document each rule in a spreadsheet before migration.
• Self-service portal flows — The customer-facing portal with order lookup, returns, and FAQ routing is Richpanel-specific. No export path exists for flow logic or branching conditions.
• Widget configurations — Chat widget appearance, behavior settings, and placement rules stay in Richpanel.
• Analytics and insights — Richpanel explicitly states that analytics-derived data is not subject to data portability. Export reports manually as CSVs or screenshots before canceling your subscription.
• Knowledge base articles — No documented bulk export endpoint for help center content. Options: manual copy, browser-based scraping of the public-facing portal, or contact Richpanel support.
• Macro / canned response libraries — No API endpoint for bulk extraction. Document each macro manually or export via browser developer tools if accessible in the DOM.
• CSAT survey templates — The survey configuration itself doesn't export; only individual response scores (rating, rating_comment) are available on conversation objects through the API.

Document your automation rules, macros, and self-service flows before migration starts. Do not assume you will reconstruct this from memory.

Preserving Shopify Order Links

This edge case catches most e-commerce teams off guard. Richpanel embeds Shopify order IDs into conversation metadata as relational references. When you extract via CSV or API, these are bare ID strings — they only resolve in a target system that can match them to actual Shopify order records.

Build a four-column lookup table before importing:

1. Extract all conversations with their linked Richpanel order IDs.
2. Extract all orders with their Shopify order IDs and customer emails.
3. Map: Richpanel conversation ID → Richpanel order ID → Shopify order ID → customer email.
4. On the target platform, match by Shopify order ID or customer email to restore the link.

If your target platform (Zendesk, Freshdesk, Gorgias) doesn't natively support order-level linking the way Richpanel does, store the Shopify order ID in a custom field on the imported ticket. This preserves the reference as searchable text even if it's not a clickable link to order data.

Common Failure Modes

Watch for these specific issues during mass extraction:

• Orphaned messages. API timeouts during conversation detail fetches return a comments array shorter than the message_count field. Implement a verification pass that flags any conversation where len(comments) != message_count.
• Large attachments. Video files of defective products can exceed 50MB. Use streaming HTTP downloads (stream=True in Python requests) and set socket timeouts of at least 120 seconds.
• Tag normalization. Tags at the conversation level often use inconsistent formats (e.g., "Refund_Requested" vs. "refund-requested"). Lowercase and deduplicate before importing to a new system to avoid tag proliferation.
• HTML vs. plain text. Email channels store HTML; live chat channels store plain text. A message body starting with < is HTML; parse accordingly. Do not apply an HTML parser to plain-text bodies — it will corrupt content.
• Response shape inconsistencies. The channels endpoint returns { "channel": [...] } while most list endpoints return { "tickets": [...] } or { "customers": [...] }. Verify the exact envelope key for each endpoint before writing a generic parser.
• 492 not caught by default retry logic. Most HTTP libraries and retry decorators treat 492 as an unknown client error, not a rate-limit signal. Test your retry handler explicitly against a 492 response before running a production extraction.

Data Staging: Extract, Transform, Load

Never pipe data directly from the Richpanel API into a target platform's API. Differing rate limits will cause cascading failures: if the destination rejects a batch at its own rate limit, you have no way to replay it without re-querying Richpanel for another 8–28 hours.

Use a decoupled three-stage approach:

1. Extract: Pull all JSON payloads from Richpanel and write them to a local database (PostgreSQL, MongoDB) or flat NDJSON files — one record per line, one file per object type. Do not transform during extraction.
2. Transform: Run secondary scripts to map status values, download attachments to permanent storage, normalize HTML bodies to plain text where required, and build the Shopify order lookup table.
3. Load: Push the sanitized local data into your target platform's API.

This decoupled approach means if your import fails halfway through, you replay from the local store — not from Richpanel.

Checkpoint your extraction. Write each page of results to disk as you go. If the extraction process crashes at page 200 of 300, resume from page 200 rather than restarting. Store the last successfully written page number in a state file.

Step-by-Step Export Checklist

1. Define scope and audit your data

• Decide: archive, BI extract, or live migration? The answer determines your tooling.
• Count total conversations, customers, and orders in Richpanel.
• Identify how many stores/brands (appClientId values) need extraction.
• Document automation rules, self-service flows, and macros manually — these don't export.

2. Generate API credentials

• REST API: Settings → Integrations → API Keys.
• Graph API: Settings → Advanced Settings → API Settings.
• Confirm your plan includes Developer API access (documented as Enterprise-only).
• Store keys in environment variables or a secrets manager — they grant read/write access.

3. Extract reference data first

• Teams, agents, tags, and channels are small datasets that complete in minutes.
• These lookup tables are needed to decode IDs in conversation and customer records.

4. Extract customer profiles

• Paginate through customers if the list endpoint is available on your workspace.
• Store in JSON or a relational database for matching against conversations later.
• Manually document custom field definitions — they are not API-accessible.

5. Extract conversations (two-pass)

• Pass 1: Paginate through all conversations at 100 per page, collecting IDs and metadata.
• Pass 2: Fetch each conversation by ID with include_private_notes=true.
• Save raw JSON to disk or database — do not transform until extraction is complete.
• Log any conversation where len(comments) != message_count for retry.

6. Extract orders and build the lookup table

• Fetch orders linked to conversations.
• Map Richpanel conversation ID → Richpanel order ID → Shopify order ID → customer email.

7. Download attachments

• Parse conversation detail responses for attachment URLs in comment objects.
• Download each file immediately with streaming and 120-second timeouts.
• Save to permanent storage with filenames encoding conversation ID and attachment ID.
• Rewrite URLs in your exported JSON before loading into the target system.

8. Validate completeness

• Compare extracted conversation count against your Richpanel dashboard total.
• Spot-check 20–30 conversations for complete message threads (compare message_count to len(comments)).
• Verify customer and order counts match expected totals.
• Run a delta pass — extract conversations created or updated during the extraction window — to capture records that changed while you were running.

GDPR and Data Retention

Richpanel's terms state that customers "shall have the ability to export or retrieve the Collected Data from the Service at any time." Operational details:

• Trial accounts: Data retained for 60 days after trial expiration. After that, deletion may occur without further notice.
• Paid accounts: Data retention terms are governed by the data processing agreement and are negotiated at contract termination.
• Analytics data: Explicitly excluded from data portability obligations — export reports manually before cancellation.
• GDPR subject requests: Contact dpo@richpanel.com for DPA requests or individual data subject access requests.

Do not wait until after contract termination to extract your data. API access requires an active account. Once the account is closed or the plan is downgraded below Enterprise, API access is no longer available.

Making the Right Call on Your Richpanel Export

Richpanel's data portability is functional but architecturally constrained. Compared to platforms like Zendesk — which provides a bulk incremental export API returning full ticket objects including comments in a single paginated stream — Richpanel's two-pass requirement and per-conversation fetch model represent a meaningfully higher extraction cost. The rate limits, two-pass extraction, and absence of bulk export endpoints mean that even a mid-sized account requires real engineering effort to extract completely.

The decision framework:

• Compliance archive only: CSV export covers metadata; use the source platform (Shopify, etc.) for order history. Acceptable if message-level history is not required.
• Full migration: REST API extraction is the only viable path. Plan for two-pass extraction, multi-day runtime for accounts over 30K conversations, and a separate attachment download pipeline.
• BI/analytics use case: API extraction to a local database is appropriate, but expect to supplement with direct exports from Shopify or BigCommerce for order-level analytics — Richpanel's analytics data does not export.

The real complexity in any Richpanel export is not the extraction itself — it's the transformation step, where you map Richpanel's order-linked conversation model to a target platform's data model. Build the Shopify order lookup table before you start importing, not after.