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)

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:

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.

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)
• Satisfaction Ratings — GET /api/v1/satisfaction_ratings (support.reamaze.com)
• 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)

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.

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

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)

What Is and Is 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:

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.

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

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)

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:

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 or Re:amaze to Gorgias 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:

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)
• 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)

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:

{
  "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

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:

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)

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—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)

Each article includes:

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

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.

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)

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:

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:

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)

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

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:

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

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.