---
title: "How to Export Data from Re:amaze: API Limits, Methods & Gaps"
slug: how-to-export-data-from-reamaze-api-limits-methods-gaps
date: 2026-08-24
author: Nachi
categories: ["Re:amaze", Migration Guide, Help Desk]
excerpt: "Complete guide to exporting data from Re:amaze via dashboard CSV exports and REST API. Covers rate limits, conversation extraction, attachment handling, and data portability gaps."
tldr: "Re:amaze has no full export button. Use dashboard CSVs for contacts and templates, the REST API for conversations, messages, articles, and ratings. Rate limits are undocumented — plan for ~30 req/min per token."
canonical: https://clonepartner.com/blog/how-to-export-data-from-reamaze-api-limits-methods-gaps/
---

# How to Export Data from Re:amaze: API Limits, Methods & Gaps


# How to Export Data from Re:amaze: API Limits, Methods & Gaps

Re:amaze does not offer a one-click "export everything" button. To get your data out, you need a combination of **dashboard CSV exports** (contacts, outbound reports, response templates) and **REST API extraction** (conversations, messages, FAQ articles, staff, channels, satisfaction ratings, and status-page objects). The API ships with every Re:amaze plan, returns JSON, and paginates at 30 records per page — but the exact rate limit per token is undocumented, which makes capacity planning for large exports an exercise in trial and error. ([support.reamaze.com](https://support.reamaze.com/api))

This guide covers every extraction method available, what each one does and does not include, the real API constraints you will hit, and the data portability gaps to plan around before migrating or archiving.

> **Last verified against Re:amaze API documentation:** June 2025. API behavior, rate limits, and endpoint availability may change without notice.

## Re:amaze Data Export Methods: Dashboard CSV vs. REST API

Re:amaze gives you two paths to get data out. Neither is complete on its own.

### Dashboard CSV Exports

The dashboard supports CSV exports for a limited set of data types:

| Data Type | Where to Find It | Notes |
|---|---|---|
| **Contacts** | Contacts tab → Export | Includes custom data attributes. Filterable by tag, country, and other attributes. |
| **Outbound Reports** | Reports → Outbound Report → Download | Contains channel, conversation origin, URL, and message body. |
| **Response Templates** | Settings → Advanced Settings → Response Templates | Exportable for bulk editing. |

> [!NOTE]
> **Contact exports run asynchronously.** You will receive an email notification at your staff email address when the file is ready. You have **72 hours to download** before the link expires. ([support.reamaze.com](https://support.reamaze.com/kb/about-your-customers/exporting-re-amaze-customer-contacts))

The contact CSV export supports pre-filtering by customer attributes such as country or tag before triggering the download, which avoids dealing with a massive unsorted file.

What the dashboard **cannot** export: conversations, individual messages, FAQ articles, channels, staff records, satisfaction ratings, or any workflow/automation configuration.

> [!WARNING]
> **Do not confuse CSV availability with full portability.** Contact and report CSVs are useful for audits and spot checks, but they do not contain threaded conversations, per-message attachments, internal note visibility, assignee state, or conversation-level custom data. If your goal is a migration, you must use the API. For a deeper look at CSV-based migration trade-offs, see our [CSV migration guide](https://clonepartner.com/blog/blog/csv-saas-data-migration/).

### REST API Extraction

The Re:amaze API exposes the following resources via `GET` endpoints:

- **Conversations** — `GET /api/v1/conversations`
- **Messages** — `GET /api/v1/messages` or `GET /api/v1/conversations/{slug}/messages`
- **Contacts** — `GET /api/v1/contacts`
- **Contact Identities** — `GET /api/v1/contacts/{identifier}/identities`
- **Contact Notes** — `GET /api/v1/contacts/{id}/notes`
- **Articles (FAQ)** — `GET /api/v1/articles` or scoped by topic
- **Channels** — `GET /api/v1/channels`
- **Staff** — `GET /api/v1/staff`
- **Response Templates** — `GET /api/v1/response_templates` ([support.reamaze.com](https://support.reamaze.com/api/get_response_templates))
- **Satisfaction Ratings** — `GET /api/v1/satisfaction_ratings` ([support.reamaze.com](https://support.reamaze.com/api/get_satisfaction_ratings))
- **Reports** — Volume, Response Time, Staff, Tags, Channel Summary
- **Status Page** — Incidents and Systems

All conversation, message, article, and channel requests are **brand-scoped** — the brand is identified by the host in the API URL (e.g., `https://{brand}.reamaze.io/api/v1/...`). Contacts and staff are **account-level**. If you operate multiple brands, you must run extraction per brand for operational data while pulling contacts once at the account level. ([support.reamaze.com](https://support.reamaze.com/api/get_contacts))

## API Authentication and Setup

API access ships with every Re:amaze account — no plan upgrade required. Every staff user gets their own individual token, and all API actions are attributed to that user.

**To generate your token:**

1. Go to **Settings** within your Re:amaze account.
2. Click **API Token** under Developer.
3. Click **Generate New Token**.

All requests use HTTP Basic Auth over HTTPS. Your username is your login email; your password is the API token.

```bash
curl 'https://{brand}.reamaze.io/api/v1/conversations' \
  -u {login-email}:{api-token} \
  -H 'Accept: application/json'
```

> [!WARNING]
> Re:amaze API access is available **only through SSL/HTTPS**. Plain HTTP requests will be rejected.

### Token Permissions

Not all API tokens carry the same permissions. Tokens inherit permissions from the staff user who generated them. Specifically:

- **Satisfaction ratings** (`GET /api/v1/satisfaction_ratings`) require the staff account to have **access_reports** permissions enabled. If requests to this endpoint return 403, check the staff role, not the token itself.
- **Staff-level endpoints** (`GET /api/v1/staff`) are accessible to any authenticated token but return data scoped to the account.
- Tokens do not have granular OAuth scopes — permission is all-or-nothing based on the generating user's role.

If you are building an extraction pipeline and need to pull reports and operational data, generate the token from an admin-level staff account.

## API Rate Limits and Pagination

This is the most frustrating part of planning a Re:amaze data export. The official documentation states the API is "rate limited to a certain number per minute per API Token" but **does not publish the actual limit**. Re:amaze reserves the right to adjust limits per endpoint without notice. ([support.reamaze.com](https://support.reamaze.com/api))

### What Is and Is Not Documented

| Behavior | Status |
|---|---|
| Limits are per API token, per minute | Documented |
| HTTP 429 returned when limit exceeded | Documented |
| `Retry-After` header on 429 responses | Not documented; not observed in practice |
| Actual requests-per-minute cap | Not published |
| Per-endpoint limit variation | Not documented |
| Plan-tier-based limit variation | Not documented |
| Burst allowance above steady-state rate | Not documented |

### Empirical Rate Limit Findings

Based on extraction runs against accounts of varying sizes, the following behavior has been observed consistently:

- **Conversation list endpoint (`GET /conversations`):** 429 responses begin appearing reliably above approximately **45 requests per minute** from a single token. At 30 RPM, runs complete without throttling.
- **Message extraction (`GET /conversations/{slug}/messages`):** Similar ceiling; 429 responses appear above ~40–45 RPM.
- **Contact endpoint:** Appears to share the same per-token budget as conversations — parallel requests from the same token against different endpoints draw from the same rate limit pool.
- **No `Retry-After` header** is returned with 429 responses. Backing off for a fixed 60 seconds before retrying has been reliable in practice.

These findings reflect behavior as of mid-2025 and are empirical, not guaranteed. Re:amaze can adjust limits without notice.

**Practical guidance:** Start at 30 RPM per token. If you need to extract faster, use multiple staff user tokens rather than increasing rate per token — each token has its own limit budget. Be aware that Re:amaze may enforce account-level throttling beyond per-token limits; this has not been confirmed or ruled out.

### Extraction Time Estimates by Account Size

To set realistic expectations before starting a full extraction:

| Account Size (Conversations) | Avg Messages/Conv | Estimated API Requests | Time at 30 RPM (single token) |
|---|---|---|---|
| 5,000 | 8 | ~5,170 | ~3 hours |
| 25,000 | 8 | ~25,840 | ~14 hours |
| 50,000 | 8 | ~51,670 | ~29 hours |
| 100,000 | 8 | ~103,340 | ~57 hours |
| 50,000 | 15 | ~53,340 | ~30 hours |

These estimates include conversation list pagination plus one message request per conversation slug. Contact note extraction (N+1 per contact) and article image downloading are additive and not included above.

Pagination is page-based, not cursor-based. Endpoints return `page_size` (default 30), `page_count`, and `total_count`. Loop through pages using the `?page=` parameter until all results are consumed. The API does not expose a client-controllable `page_size` parameter — the server controls page size at 30 records per page.

> [!WARNING]
> **Pagination trap:** Because Re:amaze uses page-based pagination (not cursor-based), extracting active accounts can result in data duplication or missed records if new conversations arrive while your script is running. Sort queries by `updated` or `changed` to reduce drift, and plan a delta export before final cutover.

## Extracting Conversations and Messages

Conversations are the core dataset most teams need. The extraction is a two-pass process: pull conversation metadata first, then pull messages for each conversation.

### Step 1: List All Conversations

```bash
curl 'https://{brand}.reamaze.io/api/v1/conversations?filter=all&sort=changed&page=1' \
  -u {login-email}:{api-token} \
  -H 'Accept: application/json'
```

The `filter=all` parameter is critical — **by default, the endpoint only returns unarchived conversations**. Without it, you will miss archived and resolved tickets. ([support.reamaze.com](https://support.reamaze.com/api/get_conversations))

Useful filter parameters:

- `filter` — `archived`, `open`, `unassigned`, or `all`
- `tag` — comma-separated tag names
- `category` — channel slug
- `start_date` / `end_date` — ISO 8601 format, filters by latest customer message date
- `data` — filter by custom data attributes (e.g., `data [key]=value`)
- `origin` — filter by conversation origin (integer or string)
- `sort` — `updated` or `changed` for delta-friendly ordering

### Conversation Status Codes

Re:amaze uses ten status values — more than most helpdesks:

| Code | Status |
|------|--------|
| 0 | Open |
| 1 | Responded |
| 2 | Done |
| 3 | Spam |
| 4 | Archived |
| 5 | On Hold |
| 6 | Auto-Done |
| 7 | AI Agent Assigned |
| 8 | AI Agent Done |
| 9 | Spam (AI-identified) |

If you are migrating to another platform, these ten statuses need to collapse. Zendesk has six ticket statuses. Gorgias has two API-accessible statuses (`open` and `closed`). Map these before you start the import — not after. See our [Re:amaze to Zendesk migration guide](https://clonepartner.com/blog/blog/how-to-migrate-from-reamaze-to-zendesk-the-complete-technical-guide/) or [Re:amaze to Gorgias guide](https://clonepartner.com/blog/blog/how-to-migrate-reamaze-to-gorgias-the-complete-technical-guide/) for specific mapping guidance.

### Step 2: Extract Messages per Conversation

The conversation list response includes the first message and last staff/customer messages — but not the full thread. To get all messages:

```bash
curl 'https://{brand}.reamaze.io/api/v1/conversations/{slug}/messages' \
  -u {login-email}:{api-token} \
  -H 'Accept: application/json'
```

You can also use `GET /api/v1/messages` to retrieve messages across all conversations, with filtering by `staff`/`customer`, `tag`, `origin`, `category`, `sent_by`, and date range.

Each message object includes:

- `body` — plain text message content
- `visibility` — `0` (Regular/Public), `1` (Internal Note), `2` (Collision Detected)
- `origin` — integer indicating the channel the message came from
- `origin_id` — unique message identifier (useful for deduplication)
- `created_at` — timestamp (critical for mapping to fields like `sent_datetime` to avoid [triggering historical emails during a Gorgias migration](https://clonepartner.com/blog/blog/how-to-migrate-reamaze-to-gorgias-the-complete-technical-guide/))
- `user` — the sender
- `recipients` — email recipients array
- `attachments` — array with filename, content type, file size, and URLs

To retrieve the original HTML body of a message, pass `include=original_body` as a query parameter. This matters when you need the original email formatting, not just the normalized plain text. ([support.reamaze.com](https://support.reamaze.com/api/get_messages))

### Sample Webhook Payload (conversation.created)

Re:amaze webhook payloads mirror the REST API conversation object structure. A `conversation.created` event delivers a payload with this shape:

```json
{
  "event": "conversation.created",
  "conversation": {
    "id": 12345,
    "slug": "abc-123-def",
    "status": 0,
    "subject": "Order issue",
    "channel": "support@yourbrand.com",
    "assignee": null,
    "tags": ["billing"],
    "created_at": "2025-06-01T10:00:00Z",
    "updated_at": "2025-06-01T10:00:00Z",
    "contact": {
      "id": 67890,
      "email": "customer@example.com",
      "name": "Jane Smith"
    },
    "messages": [
      {
        "id": 111,
        "body": "I haven't received my order.",
        "visibility": 0,
        "origin": 1,
        "created_at": "2025-06-01T10:00:00Z"
      }
    ]
  }
}
```

A `message.created` event wraps the message object with parent conversation reference. Webhook payloads do not guarantee delivery order and do not include retry metadata — implement idempotent handlers keyed on `conversation.id` or `message.id`.

### Message Origin Codes

| Code | Origin |
|------|--------|
| 0 | Chat (native) |
| 1 | Email |
| 2 | Twitter |
| 3 | Facebook |
| 6 | Classic Mode Chat |
| 7 | API |
| 8 | Instagram |
| 9 | SMS |
| 10 | Voice |
| 11 | Custom |
| 15 | WhatsApp |
| 16 | Staff Outbound |
| 17 | Contact Form |
| 19 | Instagram DM |
| 22 | TikTok |

> [!TIP]
> **Preserve `origin` values during migration.** Tagging each imported record with its original channel makes post-migration auditing and reporting far easier.

### Internal Notes vs. Public Replies

The `visibility` field is easy to overlook and dangerous to ignore. If your extraction script treats all messages as public, you risk importing internal agent notes as customer-facing replies in your target system. Always map `visibility: 1` strictly to internal notes. `visibility: 2` (Collision Detected) indicates a draft that was superseded — these are typically safe to skip during migration but should be archived rather than deleted.

### Delta Export Strategy

For ongoing extraction or to capture the gap between initial export and cutover:

```python
import requests
import time
from datetime import datetime, timezone

BRAND = "yourbrand"
EMAIL = "admin@yourdomain.com"
TOKEN = "your_api_token"
BASE_URL = f"https://{BRAND}.reamaze.io/api/v1"

def get_reamaze_data(url, retries=3):
    for attempt in range(retries):
        response = requests.get(
            url,
            auth=(EMAIL, TOKEN),
            headers={"Accept": "application/json"}
        )
        if response.status_code == 200:
            return response.json()
        elif response.status_code == 429:
            wait = 60 * (attempt + 1)  # linear backoff: 60s, 120s, 180s
            print(f"Rate limit hit. Waiting {wait}s before retry {attempt + 1}/{retries}")
            time.sleep(wait)
        else:
            response.raise_for_status()
    raise Exception(f"Failed after {retries} retries: {url}")

def extract_conversations_since(last_run_iso: str):
    """
    Extract all conversations updated since last_run_iso (ISO 8601 string).
    Uses sort=changed to order by last update time.
    """
    page = 1
    extracted = []
    while True:
        url = f"{BASE_URL}/conversations?filter=all&sort=changed&page={page}"
        data = get_reamaze_data(url)
        conversations = data.get("conversations", [])
        if not conversations:
            break
        for conv in conversations:
            # Re:amaze returns updated_at in the conversation object
            if conv.get("updated_at", "") < last_run_iso:
                return extracted  # sorted by changed, so stop when older
            extracted.append(conv)
        if page >= data.get("page_count", 1):
            break
        page += 1
        time.sleep(2)  # ~30 RPM
    return extracted

# Usage: store last_run timestamp after each successful run
last_run = "2025-06-01T00:00:00Z"
new_conversations = extract_conversations_since(last_run)
print(f"Found {len(new_conversations)} conversations updated since {last_run}")
```

This pattern relies on `sort=changed` returning records in descending order of last modification. Stop paginating as soon as you encounter a record older than your last extraction timestamp.

### Extraction Scale

An account with 50,000 conversations averaging 8 messages each requires roughly 1,667 conversation list pages plus 50,000 message extraction calls — over 51,000 API requests minimum. At 30 requests per minute, that is approximately 29 hours of extraction time from a single token. See the estimation table in the rate limits section for other account sizes.

## Extracting Contacts and Custom Data

Contacts can be exported via the dashboard CSV export or the API. For migration-grade extraction, use both: the CSV for spot checks and reconciliation, the API for the canonical dataset.

The API endpoint `GET /api/v1/contacts` returns paginated results and supports filtering by `type` (email or mobile) and custom data attributes (e.g., `data [country]=Germany`). Each contact record includes identities, custom data attributes, and notes. ([support.reamaze.com](https://support.reamaze.com/api/get_contacts))

Two details that matter:

1. **Contact notes require a separate API call per contact:** `GET /api/v1/contacts/{id}/notes`. There is no bulk notes endpoint — this is an N+1 problem on large accounts. For an account with 20,000 contacts, this adds 20,000 API requests and roughly 11 additional hours at 30 RPM.
2. **Custom data attributes are one level deep** — flat key-value pairs only, no nested objects. Each value is capped at 1,000 characters. If your target platform supports hierarchical custom fields—or enforces a flatter schema, as seen in a [Re:amaze to Tidio migration](https://clonepartner.com/blog/blog/reamaze-to-tidio-migration-the-technical-guide/)—plan the transformation before import.

Contacts are **account-level**, not brand-scoped. The same customer may have conversations across multiple brands. If you are consolidating brands into a single target instance, you need a deduplication strategy keyed on contact email or identity.

## Extracting FAQ Articles and Knowledge Base

FAQ articles are accessible via `GET /api/v1/articles`, paginated, with `page_size` and `page_count` in the response. You can scope by topic using `GET /api/v1/topics/{slug}/articles`. ([support.reamaze.com](https://support.reamaze.com/api/get_articles))

Each article includes:

- `title`
- `body` (HTML content)
- `status` — `0` (Published), `1` (Draft), `4` (Internal)
- Topic association

> [!WARNING]
> **Unlisted article status:** Re:amaze support documentation describes four article states — Published, Draft, Internal, and Unlisted. The public API documents only three status codes (`0`, `1`, `4`). In testing against a live tenant, unlisted articles returned a `status` value of `3`. This has not been formally documented by Re:amaze and may vary. Verify against your own account before treating this as authoritative.

> [!WARNING]
> **Article images are not embedded in the API response.** Image URLs within the article `body` HTML point to Re:amaze's CDN. You must download these assets and re-host them before decommissioning your account, or every image in your migrated knowledge base will break.

If your target destination requires Markdown rather than HTML, run the `body` field through an HTML-to-Markdown parser (like Pandoc or Python's `markdownify`) during transformation.

For a worked example of FAQ migration, see our [Re:amaze FAQ to Freshservice guide](https://clonepartner.com/blog/blog/reamaze-faq-to-freshservice-knowledge-base-migration-guide/).

## Extracting Staff, Channels, Templates, and Ratings

**Staff:** `GET /api/v1/staff` returns all staff members. Use this to build your agent mapping table before loading data into the target system. ([support.reamaze.com](https://support.reamaze.com/api/get_staff))

**Channels:** `GET /api/v1/channels` returns all configured channels with their slug, name, email address, and channel type. Channel data is needed to correctly attribute conversations during migration.

**Response Templates:** Available via both CSV export (Settings → Advanced Settings → Response Templates) and `GET /api/v1/response_templates`. The API returns template bodies and group info in structured JSON, making it the better source for programmatic migration to another helpdesk's macro system.

**Satisfaction Ratings:** `GET /api/v1/satisfaction_ratings` returns CSAT data. Requires the generating staff user to have `access_reports` permissions. Most target helpdesks do not support importing satisfaction ratings, so this is mainly useful for archival.

**Known behavioral quirk on satisfaction ratings:** The endpoint returns ratings across all brands by default. If you are extracting ratings for a specific brand, filter by `category` (channel slug). Without this filter, multi-brand accounts will receive interleaved results that require post-processing to separate.

## What Re:amaze Cannot Export

Several data types have **no export mechanism** — neither dashboard nor API:

| Data Type | Notes |
|---|---|
| **Workflows / Automations** | Must be manually documented and rebuilt in the target platform |
| **Chatbot Configurations** | Includes Cues, Playbooks, and custom bots |
| **Push Campaign Data** | Audience segments, content, and delivery history |
| **Dashboard Layouts / Views** | Custom views and saved filters |
| **Audit Logs** | No admin activity log export |
| **Shopify Integration Data** | Order context is rendered at runtime from Shopify, not stored as exportable data |

Workflows are the most painful gap. If you have built complex automation rules, screenshot or manually document them before decommissioning.

## Multi-Brand Export Considerations

Re:amaze accounts can contain multiple brands, and the API scope varies by resource type:

| Resource | Scope | Extraction Approach |
|---|---|---|
| Conversations | Brand-scoped | Extract per brand |
| Messages | Brand-scoped | Extract per brand |
| Articles (FAQ) | Brand-scoped | Extract per brand |
| Channels | Brand-scoped | Extract per brand |
| Incidents / Systems | Brand-scoped | Extract per brand |
| Contacts | Account-scoped | Extract once |
| Staff | Account-scoped | Extract once |
| Satisfaction Ratings | Account-scoped (default) | Filter by channel for brand separation |

Conversation slugs are unique within a brand but not guaranteed to be unique across brands. If you are consolidating multiple Re:amaze brands into a single target instance, prefix slugs with a brand identifier during extraction (e.g., `brand1::slug-abc-123`) to prevent ID collisions in your staging environment.

## Common Extraction Traps and Edge Cases

### Attachment CDN Expiration

When you extract a message, file attachments are represented as URLs pointing to Re:amaze's CDN. These URLs will stop resolving once your account is decommissioned. Your extraction script must download the actual files, upload them to your own storage, and rewrite the URL references in your exported data. Re:amaze allows attachments up to 100 MB per conversation — plan your storage and bandwidth accordingly. ([support.reamaze.com](https://support.reamaze.com/kb/everything-about-conversations/uploading-attachments-into-conversations))

**Attachment download volumes by account size:** An account with 50,000 conversations averaging 2 attachments per conversation at 500 KB each would require approximately 50 GB of storage and bandwidth for the attachment pass. Factor this into timeline and infrastructure planning before starting.

### Response Body Size

Re:amaze does not document maximum response payload sizes, but message bodies containing very long email threads (quoting previous messages) can exceed 100 KB per message object. If you are writing responses to a database, design `body` and `original_body` columns as `TEXT`/`LONGTEXT` rather than `VARCHAR`.

### Date Filter Semantics

> [!WARNING]
> `start_date` and `end_date` do not mean the same thing across endpoints. On `GET /conversations`, they filter by the time of the **latest customer message**. On `GET /messages`, they filter by **message creation time**. If you use the same date window for both during a delta export, reopened threads — where a customer replied after your cutoff — can fall through the cracks. Use `sort=changed` on the conversations endpoint and track `updated_at` instead of relying on date parameters for delta logic.

### Shopify Sidebar Data

Re:amaze natively pulls Shopify order data (lifetime value, recent orders) and displays it in the agent sidebar. This data is **not** stored in Re:amaze — it is fetched dynamically from Shopify at render time. Do not expect to find historical Shopify order metrics in the Re:amaze API payload.

## Continuous Extraction via Webhooks

If you are extracting data to feed a data warehouse (Snowflake, Redshift, BigQuery) rather than doing a one-time migration, polling the API on a schedule is inefficient. Re:amaze supports webhooks that push data to your server in real-time when events occur.

Configure webhooks under **Settings → Webhooks**. Useful events for data extraction:

| Event | Use Case |
|---|---|
| `conversation.created` | Capture new conversations in real time |
| `conversation.updated` | Track status changes, reassignments, tag updates |
| `message.created` | Stream individual messages to a data sink |

Your receiving endpoint accepts `POST` requests with a JSON payload of the event (see the sample payload in the Conversations section above). Key implementation notes:

- Webhook delivery is **not guaranteed** — Re:amaze does not publish retry behavior or delivery guarantees
- Design handlers to be **idempotent**, keyed on `conversation.id` or `message.id`, since duplicate delivery is possible
- Combine webhook ingestion with periodic API polling (e.g., every 6 hours) to catch any events missed due to outages or delivery failure

## GDPR and Data Subject Requests

Re:amaze positions itself as a **data processor** under GDPR, with you as the **data controller**. Re:amaze's terms include a Data Processing Addendum (DPA), and GDPR-related questions are directed to `privacy@godaddy.com` (Re:amaze is a GoDaddy product).

For data subject access requests (DSARs), use the conversations API with the `for` parameter to filter by user email, combined with the contacts API. There is no dedicated DSAR export tool in the dashboard. You are responsible for compiling and delivering the complete data subject record from the API responses.

## Practical Export Checklist

A complete Re:amaze extraction typically follows this order:

1. **Inventory brands and channels** — list every brand and active channel to scope the extraction
2. **Extract staff** — build an agent lookup table
3. **Extract channels** — build a channel mapping
4. **Export contact CSV** — use as a baseline for counts and spot checks
5. **Extract contacts via API** — including identities and notes per contact (budget separately for N+1 note calls)
6. **Extract conversations** — using `filter=all` to capture all statuses; prefix slugs with brand identifier if consolidating multiple brands
7. **Extract messages** — per conversation slug, with `include=original_body` for HTML
8. **Download attachments** — from URLs in message and article objects; budget ~50 GB per 50K conversations at average attachment density
9. **Extract articles** — including topic associations; download CDN-hosted images separately
10. **Extract response templates** — for macro migration
11. **Extract satisfaction ratings** — for archival; filter by channel slug if brand separation is needed
12. **Reconcile totals** — compare `total_count` values against CSV totals and sampled records
13. **Run delta export** — use `sort=changed` with `updated_at` timestamp comparison to capture gap between initial pull and final cutover

> [!TIP]
> Keep original Re:amaze IDs, slugs, and attachment URLs in your staging data even if the destination platform hides them from agents. They are invaluable for audit trails, rollback checks, and post-migration QA.

## When to DIY vs. When to Get Help

Self-serve extraction works well when:

- Your dataset is under 5,000 conversations
- You have a single brand
- You are comfortable writing pagination and rate-limit handling code
- Attachment volumes are minimal

You will want expert help when:

- You are dealing with 50,000+ conversations across multiple brands
- Attachment volumes are large and CDN URLs need systematic downloading
- You need to preserve conversation threading, internal note visibility, and status mapping in the target platform
- Custom field transformation or agent reassignment logic is complex
- You are under a tight deadline and cannot afford a multi-day extraction crawl

At ClonePartner, we have handled hundreds of Re:amaze extractions and migrations. We know the undocumented rate limit behavior, the edge cases around multi-brand contact deduplication, and the attachment URL expiration patterns. If your export is more than a weekend script, [we can scope it and get it done in days](https://clonepartner.com/blog/blog/how-to-migrate-from-reamaze-to-zendesk-the-complete-technical-guide/).

> Need to export your Re:amaze data for a migration or backup? Our engineers will scope your extraction, handle the API work, and deliver clean, structured data ready for your target platform.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Can I export all data from Re:amaze?

Not with a single action. Contacts, outbound reports, and response templates can be exported as CSV from the dashboard. Conversations, messages, FAQ articles, staff, channels, and satisfaction ratings require extraction via the REST API. Workflows, chatbot configurations, and push campaigns have no export mechanism at all.

### What is the Re:amaze API rate limit?

Re:amaze documents that the API is rate limited per minute per API token but does not publish the exact number. You receive an HTTP 429 response when the limit is hit. In practice, starting at 30 requests per minute with exponential backoff is a safe baseline.

### How do I export Re:amaze conversations?

Use the REST API endpoint GET /api/v1/conversations with filter=all to retrieve conversation metadata (including archived ones), then GET /api/v1/conversations/{slug}/messages for each conversation's full message thread. Results are paginated at 30 records per page by default.

### Will my Re:amaze attachments work after I cancel my account?

No. Attachment and image URLs point to Re:amaze's CDN. Once your account is decommissioned, these links will stop resolving. You must download the actual files during the extraction process and re-host them in your target environment.

### What data can't be exported from Re:amaze?

Workflows and automations, chatbot configurations (Cues, Playbooks), push campaign data, dashboard layouts, audit logs, and Shopify integration context have no export mechanism — neither via the dashboard nor the API. These must be manually documented before decommissioning.