How to Export Data from Trengo: API Limits, Methods & Gaps

How to Export Data from Trengo: API Limits, Methods & Gaps

Trengo does not offer a one-click "export everything" button. The platform's native UI exports are limited to reporting-level ticket metadata in CSV format — they do not export full conversation threads, contacts, attachments, or knowledge base content. To extract your complete dataset, you need the Trengo REST API, which returns JSON at 25 records per page with a rate limit of 120 requests per minute.

What Data Can You Export from Trengo?

Before writing any code or clicking export buttons, map Trengo's data model to your extraction requirements. Trengo is an omnichannel inbox built around Tickets, Messages, Contacts, and Profiles. Because it aggregates channels (WhatsApp, email, voice, live chat), the data structure is heavily nested. Exporting a "Ticket" is useless unless you also export the Messages inside it, the Attachments tied to those messages, and the Contact who initiated the conversation.

Trengo maintains a separation between a Contact (an addressable communication endpoint like an email or phone number) and a Profile (the holistic customer view). When exporting, you need to reconstruct this parent-child mapping yourself from the API responses — it is not included in any native export.

The table below maps every core object to its export availability.

Export Methods: Every Way to Get Data Out of Trengo

Trengo gives you three documented self-serve UI export surfaces — Ticket Details CSV, legacy Reports CSV, and single-conversation PDF — plus a broad REST API. It does not offer a whole-account bulk dump, SQL database export, or dedicated migration endpoint.

Native UI exports require zero engineering — any admin can do them in minutes. API-based exports require a developer who can write pagination logic, handle rate limiting, and transform JSON output. Third-party ETL tools like n8n or dlt sit in between: they abstract some API complexity but still need configuration and are subject to the same 120 req/min rate limit.

There is no way to get a complete Trengo export without the API being involved at some layer.

Native UI Export: Step-by-Step

Trengo offers three UI-level export paths, all limited in scope.

Export Tickets from the Ticket Details Page

Select "Download Table" to export all the tickets in the current view into a CSV format. The exported data will include all the ticket details as shown in the table.

Steps:

1. Navigate to Analytics > Ticket Details (or drill into Ticket Details from any other report).
2. Apply filters — date range, channel, agent, label, CSAT.
3. Click "Download Table" in the top-right.
4. A CSV file downloads containing the columns visible in your current table view.

What you get: Ticket number, created/closed timestamps, channel name, assigned agent, labels, status, CSAT score, and any other column shown in the table.

What you don't get: Message bodies, internal notes, attachments, contact details, custom field values on the contact/profile, or conversation threading.

Export Reports (Legacy)

Exporting data into a CSV file is a great way to run your own metrics on the data from Trengo. Exporting analytics will result in a datasheet of the requested information. Data is always shown per conversation, which gives you the opportunity to build your own graphs and views. Navigate to Reports > Export.

Steps:

1. Go to Reports > Export (legacy reporting UI).
2. Apply filters: channels, users, labels, CSAT, and a timeframe (standard presets like "Today," "Last month," or custom date ranges).
3. Add fields — select from available columns like ticket number, created date, channel name.
4. Click "Start export." Your export will be downloaded as a CSV file.

Download a Single Conversation

Head to the conversation you'd like to download, click the three dots and choose 'Download'. The ticket will now be downloaded to your computer as a PDF file.

This is useful for legal holds or individual record requests, but completely impractical for bulk export.

API-Based Export: Endpoints, Pagination, and Rate Limits

The Trengo REST API is the only path to a complete data export. Here is what you need to know before writing a single line of code.

Authentication

Trengo's API uses API key-based authentication. Generate a personal access token in your Trengo dashboard. Open the dashboard and go to Settings → API. Click "Create token" and give it a name. Copy the generated token and store it securely. Use this token as the value for the Authorization: Bearer header in all API requests.

All requests go to the base URL https://app.trengo.com/api/v2 (or https://app.trengo.eu/api/v2 for EU-hosted accounts) with headers:

Authorization: Bearer {YOUR_TOKEN}
Content-Type: application/json
Accept: application/json

Rate Limits

The current rate limit is 120 requests per minute. The API responses contains useful rate limit headers to check the remaining requests.

The key response headers are:

• x-ratelimit-limit: Always 120
• x-ratelimit-remaining: Requests left in the current window

When you hit the rate limit a HTTP-status of 429 (Too Many Requests) is returned and a header "Retry-After" & "X-RateLimit-Reset" is sent to the client. These values can be used to determine when the next call will be possible (Where "Retry-After" is the number of seconds to wait. This is the safest way as it does not matter if you have a clock-skew with the server.

Important: The 120 req/min limit is account-wide, not per-token or per-thread. Running multiple concurrent scripts or threads against the same account does not increase your total throughput — it only increases the risk of hitting 429 errors. Design concurrent fetchers to share a single rate limiter.

Pagination

Most resources have an endpoint that returns a list of data separated over multiple pages. Using the request parameter named page, you can indicate the current page.

Trengo uses page-number-based pagination with a default page size of 25 records per page. Each response includes a meta block with current_page, last_page, per_page, and total counts, plus a links block with next and prev URLs.

For very large ticket-detail exports, Trengo documents a start_after_ticket_id parameter on the GET /api/v2/reporting/details/ticket endpoint specifically to replace page-based pagination and avoid timeout issues when traversing beyond page ~400.

Core Export Endpoints

Sample API Response: Ticket Object

A truncated ticket response from GET /api/v2/tickets looks like this:

{
  "data": [
    {
      "id": 123456,
      "contact_id": 78901,
      "channel_id": 42,
      "subject": "Order #9182 not received",
      "status": "ASSIGNED",
      "assigned_to": 15,
      "team_id": 3,
      "labels": [
        {"id": 7, "name": "shipping", "color": "#ff6b6b"}
      ],
      "custom_field_values": [
        {"custom_field_id": 12, "value": "Priority"}
      ],
      "created_at": "2024-11-15T09:23:41.000000Z",
      "updated_at": "2024-11-16T14:02:18.000000Z",
      "closed_at": null
    }
  ],
  "links": {
    "first": "https://app.trengo.com/api/v2/tickets?page=1",
    "last": "https://app.trengo.com/api/v2/tickets?page=84",
    "prev": null,
    "next": "https://app.trengo.com/api/v2/tickets?page=2"
  },
  "meta": {
    "current_page": 1,
    "last_page": 84,
    "per_page": 25,
    "total": 2093
  }
}

A message object from GET /api/v2/tickets/{id}/messages includes:

{
  "id": 987654,
  "ticket_id": 123456,
  "contact_id": 78901,
  "type": "INBOUND",
  "body_text": "Hi, I haven't received my order yet.",
  "body_html": "<p>Hi, I haven't received my order yet.</p>",
  "attachments": [
    {
      "id": 5432,
      "original_name": "tracking_screenshot.png",
      "url": "https://app.trengo.com/storage/attachments/5432/tracking_screenshot.png",
      "size": 245760
    }
  ],
  "created_at": "2024-11-15T09:23:41.000000Z",
  "is_internal_note": false
}

Note: is_internal_note: true indicates an agent-only internal note. These are critical to preserve for migration — they carry context that informed agent decisions.

Throughput Math

At 120 requests per minute and 25 records per page:

• Ticket list only: 120 pages/min × 25 records = 3,000 ticket records per minute
• Tickets + messages: Each ticket requires at least 1 additional request for its messages. For 10,000 tickets: ~10,400 requests minimum (400 ticket list pages + 10,000 message requests) = ~87 minutes
• 50,000 tickets + messages: ~52,000 requests = ~7–8 hours at sustained rate, often longer with retries and attachment downloads
• 100,000 tickets + messages: ~102,000 requests minimum. At sustained rate, approximately 14–17 hours, not counting attachment downloads or multi-page message threads

These numbers assume one message-fetch request per ticket. Tickets with long threads that span multiple pages require additional requests per ticket. Very large accounts (50,000+ tickets) may take up to 48 hours due to Trengo's API rate limits.

Pagination Code Example (Python)

import requests
import time
import threading
 
BASE_URL = "https://app.trengo.com/api/v2"
HEADERS = {
    "Authorization": "Bearer YOUR_TOKEN_HERE",
    "Accept": "application/json"
}
 
# Account-wide rate limiter (shared across threads)
rate_lock = threading.Lock()
remaining_requests = 120
reset_time = time.time() + 60
 
def rate_limited_get(url, params=None):
    """Make a GET request with dynamic rate-limit awareness."""
    global remaining_requests, reset_time
 
    with rate_lock:
        now = time.time()
        if now >= reset_time:
            remaining_requests = 120
            reset_time = now + 60
        if remaining_requests <= 2:  # leave headroom
            sleep_time = reset_time - now
            if sleep_time > 0:
                time.sleep(sleep_time)
            remaining_requests = 120
            reset_time = time.time() + 60
        remaining_requests -= 1
 
    response = requests.get(url, headers=HEADERS, params=params)
 
    if response.status_code == 429:
        retry_after = int(response.headers.get("Retry-After", 60))
        time.sleep(retry_after)
        return rate_limited_get(url, params)  # retry
 
    # Update from actual headers when available
    if "x-ratelimit-remaining" in response.headers:
        with rate_lock:
            remaining_requests = int(response.headers["x-ratelimit-remaining"])
 
    response.raise_for_status()
    return response
 
def fetch_all_pages(endpoint):
    """Paginate through a Trengo API endpoint."""
    all_records = []
    page = 1
 
    while True:
        response = rate_limited_get(
            f"{BASE_URL}/{endpoint}",
            params={"page": page}
        )
        data = response.json()
        all_records.extend(data["data"])
 
        print(f"Page {page}/{data['meta']['last_page']} — "
              f"{len(all_records)}/{data['meta']['total']} records")
 
        if page >= data["meta"]["last_page"]:
            break
        page += 1
 
    return all_records
 
# Export tickets
tickets = fetch_all_pages("tickets")
 
# Export messages for each ticket
for ticket in tickets:
    ticket["messages"] = fetch_all_pages(
        f"tickets/{ticket['id']}/messages"
    )

Incremental Export Strategy

A full export is necessary for the initial backfill, but repeating it daily is wasteful. Trengo supports incremental pulls via the updated_at_gt parameter on the tickets endpoint.

Using updated_at_gt for Delta Pulls

Pass updated_at_gt as an ISO 8601 timestamp to GET /api/v2/tickets to retrieve only tickets modified since your last pull:

import json
from datetime import datetime, timezone
 
CURSOR_FILE = "last_export_cursor.json"
 
def load_cursor():
    try:
        with open(CURSOR_FILE) as f:
            return json.load(f)["last_updated_at"]
    except FileNotFoundError:
        return "2020-01-01T00:00:00.000000Z"  # initial full pull
 
def save_cursor(timestamp):
    with open(CURSOR_FILE, "w") as f:
        json.dump({"last_updated_at": timestamp}, f)
 
def incremental_ticket_export():
    cursor = load_cursor()
    all_records = []
    page = 1
    max_updated = cursor
 
    while True:
        response = rate_limited_get(
            f"{BASE_URL}/tickets",
            params={"page": page, "updated_at_gt": cursor}
        )
        data = response.json()
        all_records.extend(data["data"])
 
        for record in data["data"]:
            if record["updated_at"] > max_updated:
                max_updated = record["updated_at"]
 
        if page >= data["meta"]["last_page"]:
            break
        page += 1
 
    save_cursor(max_updated)
    return all_records

Key considerations:

• updated_at_gt returns tickets where updated_at is strictly greater than the given timestamp. A new message, status change, label change, or reassignment all update this field.
• Store your cursor in persistent storage (file, database, environment variable) — not in memory.
• The incremental pull does not capture deleted tickets. If you need deletion tracking, compare ticket IDs against your previous full export.
• For contacts and profiles, no equivalent updated_at_gt parameter is documented. You may need periodic full refreshes of these objects.

Webhooks for Real-Time Change Capture

For teams that need near-real-time sync rather than periodic batch pulls, Trengo supports outbound webhooks. Webhook events fire on specific actions and deliver a JSON payload to your configured endpoint.

Documented webhook event types include:

A webhook payload for INBOUND_MESSAGE follows this structure:

{
  "event": "INBOUND_MESSAGE",
  "ticket_id": 123456,
  "message_id": 987654,
  "contact_id": 78901,
  "channel_id": 42,
  "body": "Hi, any update on my order?",
  "created_at": "2024-11-16T14:02:18.000000Z"
}

Delivery characteristics:

• Webhooks are delivered via HTTP POST to your configured URL.
• Trengo retries failed deliveries (non-2xx responses) but does not guarantee exactly-once delivery — your receiver should be idempotent.
• Webhook configuration is managed in Settings → Developers → Webhooks or via POST /api/v2/webhooks.

Recommended approach: Use a full API export for backfill, then switch to webhooks for ongoing change capture. Use periodic incremental API pulls (updated_at_gt) as a safety net to catch any events missed due to webhook delivery failures.

Does Trengo Let You Export Attachments?

Trengo does not include attachments in any native CSV export. There is no dedicated bulk attachment export endpoint in the documented API. Attachments are embedded as URLs within message objects returned by the messages endpoint.

To download attachments:

1. Fetch messages for each ticket via GET /api/v2/tickets/{id}/messages.
2. Parse the attachments array in each message object (see the sample response above) for file URLs.
3. Download each file individually using authenticated HTTP requests.
4. Save each file locally with a directory structure like /{ticket_id}/{message_id}/{original_name} so you can reconstruct the conversation timeline in your destination platform.

Key constraints:

• Each attachment download counts against the 120 req/min rate limit.
• Inline images in HTML message bodies reference Trengo-hosted CDN URLs.
• After account cancellation, hosted attachment URLs will stop working. Download all files before you cancel.
• Downloading gigabytes of historical attachments (PDFs, screenshots, audio recordings) is I/O-intensive. Implement retry logic for network timeouts and handle HTTP 404s for files that agents deleted — metadata may persist after the file itself is gone.
• Trengo's email file uploads have a 20 MB max file size. Imported email messages support up to 5 files and 20 MB per request.

What Data Cannot Be Exported from Trengo?

The following objects and data types have no supported export path — not through the UI, and not through the documented API:

The biggest portability gap is automations. If your team has invested heavily in Trengo Journeys or AI-powered workflows, those configurations are entirely locked to the platform. Budget time to rebuild them from scratch on any target system.

Edge cases that catch teams off guard:

• Email conversations flagged as spam are permanently deleted after 14 days.
• If your Trengo email data came in through an IMAP connection, Trengo can only retrieve messages from the last 90 days on new IMAP connections, and the helper import only uploads the last 50 messages. An export cannot recover mail that never made it into Trengo in the first place.
• Trengo's terms state that data may be permanently removed 6 months after account termination. Export before you leave.
• Deleting a channel in Trengo permanently deletes all conversations and contacts from that channel. Do not reorganize channels before completing your export.

Data Format, Encoding, and Cleanup After Export

Trengo's API returns JSON with UTF-8 encoding. Native UI exports produce CSV files. Individual conversations can be downloaded as PDF.

Common issues to expect after extraction:

• HTML in message bodies: Ticket messages from email channels contain raw HTML (tables, inline styles, <img> tags referencing Trengo-hosted URLs). If your destination platform only accepts Markdown or plain text, use a library like Python's markdownify or html2text for conversion.
• Timezone handling: All created_at, updated_at, and closed_at timestamps in API responses use UTC in ISO 8601 format (e.g., 2024-11-15T09:23:41.000000Z). Explicitly declare UTC in your import script so historical tickets don't shift by hours in the target system.
• Duplicate contacts: Trengo's Contact/Profile duality means the same person may appear as multiple contacts (one per channel — email, WhatsApp, phone). Deduplication and profile mapping is your responsibility post-export. If you skip this, you will create duplicate users in your new system.
• Orphaned references: If a ticket references a deleted contact, the contact_id field will still be present but the linked record will return a 404.
• Special characters: Dutch and other European language characters (common for Trengo's EU-heavy customer base) export cleanly in UTF-8 but may cause issues if opened in Excel without specifying UTF-8 encoding. In Excel, use Data → From Text/CSV and explicitly select UTF-8.

Post-Export Validation Checklist

Run this checklist after every Trengo export:

1. ☐ Total ticket count matches Trengo's dashboard count
2. ☐ Message count per ticket matches the UI thread length (spot-check 10–20 tickets)
3. ☐ Contact count matches the Contacts section in Trengo
4. ☐ Custom field values are populated (not null/empty) for records that have them
5. ☐ Attachments downloaded successfully and are openable
6. ☐ Label/tag associations are present on exported tickets
7. ☐ Timestamps parse correctly in your target system's timezone
8. ☐ Knowledge base articles render properly (HTML intact, images loading)
9. ☐ Profile-to-contact relationships are preserved, not split into unrelated records
10. ☐ ID mappings preserved: ticket_id, contact_id, profile_id, user_id, team_id, label IDs

Export for Migration vs. Backup vs. Compliance

Your extraction strategy changes based on your goal. The mechanics overlap, but the success criteria and extraction order differ.

Migration

You need data shaped for import into a target platform (Zendesk, Freshdesk, Intercom, Help Scout). This means:

• Extraction order matters: Extract Users and Teams first, Contacts and Profiles second, Tickets and Messages third. This ensures foreign key references resolve correctly during import.
• ID mapping tables: Create a mapping file (CSV or JSON) that pairs Trengo ticket IDs, contact IDs, and agent IDs to their new-platform equivalents.
• Relationship preservation: Contact → Profile associations, ticket → label associations, message → ticket threading must all survive.
• Agent matching: Trengo agent IDs must be mapped to target platform user IDs before importing tickets with correct assignment.
• Attachments need to be re-uploaded, not just linked — Trengo-hosted URLs will die when you cancel.

See our migration guides for specific destination platforms: Trengo to Zendesk, Trengo to Help Scout, Trengo to Freshdesk, or Trengo to Intercom.

Backup

You need a full-fidelity snapshot for archival. Requirements:

• Export all tickets with full message threads, including internal notes
• Download all attachments and store them alongside conversation data
• Preserve metadata: timestamps, agent assignments, labels, custom field values
• Store in a searchable, self-contained format (JSON + files in a ZIP archive with a manifest)
• Schedule periodic incremental backups using updated_at_gt if you plan to remain on Trengo

Trengo's terms state the customer is responsible for making backups. Data may be permanently removed after 6 months from termination. Deleting a channel permanently deletes all conversations and contacts from that channel.

Compliance (GDPR / DSAR)

Trengo won't process personal data in a way that doesn't comply with applicable data protection legislation, in particular the GDPR. Under GDPR Article 20, data subjects have the right to receive their personal data in a structured, machine-readable format.

Trengo does not offer a self-serve "download my data" button for individual data subjects. To fulfill a DSAR (Data Subject Access Request), you need to:

1. Search for the contact by email or phone via GET /api/v2/contacts?term={email}.
2. Retrieve all tickets associated with that contact via GET /api/v2/tickets?contact_id={id}.
3. Fetch all messages within those tickets.
4. Download any attachments tied to those messages.
5. Package everything in a machine-readable format (JSON or CSV) and deliver it to the data subject within the 30-day GDPR deadline.

If you handle frequent DSARs, build a reusable script parameterized by contact email/phone. The workflow above typically requires 5–50 API requests per data subject depending on ticket volume.

Trengo acts as a data processor under GDPR. Their Data Processing Agreement (DPA) is available on request and covers sub-processor disclosure. If your compliance team needs the sub-processor list, request it from Trengo support directly — it is not published in the public API documentation.

Vendor Lock-In and Data Portability Assessment

Trengo's data portability: Mostly portable at the data layer. Locked at the behavior layer.

The record layer — tickets, messages, contacts, profiles, labels, custom fields — is extractable through the API. The behavior layer — automations, routing rules, channel setup, integration wiring, AI agent configuration — is not. That behavior layer must be rebuilt manually on any target platform.

The real switching cost is not the data extraction itself. It is the engineering hours spent on pagination scripts plus the time rebuilding Journeys, reconnecting WhatsApp Business API channels, and reconfiguring integrations. The lack of a bulk export endpoint imposes a high switching cost in developer time — expect 1–3 weeks of engineering effort for accounts over 100K tickets.

No known contractual or ToS restrictions prevent you from exporting your own data via the API. Trengo's built-in export only covers basic report statistics (aggregated analytics). It does not export your actual ticket conversations, contacts, or attachments. For a full data export, you need the API or a service. Trengo's API is available on all paid plans.

Timeline and Resourcing for a Full Data Export

Phase breakdown:

1. Scoping (2–4 hours): Identify which objects to export, document custom fields, count records via API meta.total values.
2. API access provisioning (15 minutes): Generate a personal access token in Settings → API.
3. Script development (4–8 hours): Build pagination, rate-limit backoff using response headers, error handling with retry logic, and output serialization to JSON files.
4. Extraction (varies): Actual API pull time depends on volume — see throughput math above. For 50K tickets with messages: 7–48 hours.
5. Validation (2–4 hours): Spot-check counts, relationships, and data integrity against the Trengo UI using the checklist above.
6. Cleanup and transformation (2–8 hours): Convert to target format, deduplicate contacts against profiles, strip or convert HTML if needed.

When API Extraction Exceeds Internal Capacity

Two scenarios where custom scripting becomes impractical:

1. Your engineering team is allocated to product work and cannot spend 1–3 weeks on a disposable ETL pipeline for a one-time migration.
2. The destination platform has a different data model (e.g., Zendesk's requester/submitter distinction vs. Trengo's contact/profile model) and the transformation logic is non-trivial.

In these cases, evaluate third-party options based on: whether they handle attachment re-upload, whether they preserve internal notes and timestamps, whether they offer a dry-run mode before cutover, and whether they can run the migration without requiring Trengo downtime.

If this export is the first step in a migration, the next useful reads are Trengo to Zendesk, Trengo to Help Scout, Trengo to Freshdesk, and the Help Desk Data Migration Playbook.