Workflow Guide

Export Intercom Data to PostgreSQL

Intercom documents no direct sync to PostgreSQL in the developer and help pages opened for this guide. The documented path is export then load: take the data out of Intercom through the Data Export API, a dataset CSV, or the cloud storage export, then load the resulting files into PostgreSQL. This guide keeps those two halves separate, so each half can be checked on its own.

No direct sync: say so first

Intercom documents several ways to get data out, and a cloud storage export to Amazon S3 or Google Cloud Storage. None of the Intercom help or developer pages opened documents a direct sync, connector, or destination setting for PostgreSQL. The work is in two halves. First, export from Intercom in a format you can store. Second, load that stored file into PostgreSQL.

For the full set of Intercom export routes, see the Intercom export methods directory. For Mailchimp destinations, see the Mailchimp exports by destination directory.

Choose the export by what you need

The choice turns on one question: do you need the words people wrote, or only the numbers around them? Intercom states the distinction plainly. CSV exports provide metadata summaries, whereas message content or full conversations require the Conversations API or Amazon S3 exports.

Route 1: the Data Export API

The Intercom API documents a data export endpoint for viewing all messages sent and viewed in a given time frame. To create an export job, send a POST request to the export endpoint at https://api.intercom.io/export/content/data. The only parameters you need to provide are the range of dates you want exported: created_at_after and created_at_before, each required, each formatted as a Unix timestamp. Date ranges are inclusive. The time frame includes only messages sent during the time period, not messages that were only updated during the period.

One limit governs this route. You can only have one active job per workspace. A second concurrent job returns HTTP status code 429.

To view the status of a job, send a GET request to the export endpoint with the job identifier returned when the job was created. When a job is complete, the response includes a download_url. Jobs that have completed processing expire two days from when the export completed. After that, the data will no longer be available, so download promptly. Exported message data is streamed back in a gzipped CSV format, and the docs state you must specify the header Accept with the value application/octet-stream when hitting that endpoint.

Route 2: dataset CSV, for metadata only

For a dated, repeatable export, use the dataset CSV export in Reports and Dataset export. Intercom describes it as a flexible CSV export feature, where you can choose exactly what data you need and schedule automatic exports. The walkthrough on the help page shows selecting a dataset, choosing a time period, selecting columns, previewing the data, and clicking Export CSV. Scheduled exports can be set up from the same flow.

Load a dataset CSV into PostgreSQL only for metadata analysis. Do not treat it as a transcript store.

Route 3: cloud storage export, for JSON at scale

For continuous or large scale conversation exports, Intercom documents a data export to Amazon S3 or Google Cloud Storage. The documented options include a Data API version, an output format, and a toggle for including attachments. Exported files are JSON or JSONL, organized in day dated folders if that option is selected. Each JSON file contains JSON formatted conversation data, with a maximum of 200 conversations per file.

The schedule options are hourly or daily for periodic exports, with an option to export historical data for the last two years. Each periodic file contains all new and updated conversations for that period, with each JSON object containing the entire conversation with all parts, not a delta from the previous export.

This route produces JSON, not CSV. Loading it into PostgreSQL means parsing JSON files into tables, which is a separate step from a CSV load.

Route 4: the Conversations API and contacts search

For large scale exports, Intercom states that you can use its Conversations API to retrieve full conversation content in bulk. The help page does not give the endpoint steps in the text opened, so this guide does not invent them. Use the Conversations API reference in the Intercom developer docs for the list and retrieve calls, and page through results as the API requires.

For contacts, the Intercom API documents a search endpoint: send a POST request to https://api.intercom.io/contacts/search with a query object in the body defining filters. Search results return contact objects as JSON. There is no CSV step in that endpoint. To get contacts into PostgreSQL through this route, retrieve the JSON, convert it to rows in your own code, and then load the rows. The conversion is your code, not an Intercom export feature.

Load the export into PostgreSQL

PostgreSQL documents the COPY command for moving data between PostgreSQL tables and standard file system files. COPY FROM copies data from a file to a table, appending the data to whatever is in the table already. In CSV mode, the HEADER option specifies that the file contains a header line, and on input, the first line is ignored.

Before loading, create a table whose columns match the columns in the exported file, in the order the file uses, or name the columns explicitly in the COPY statement. Check the header row of the exported file first. Intercom notes that some attributes in the new data export have different names from their counterparts in the old export, giving Inbound and Outbound becoming Started by as an example. Do not assume column names from an old load will match a new export.

Open flags

No direct Intercom to PostgreSQL sync, and no plan limit for the exports described, was documented in the official pages opened, beyond the limits stated above: one active Data Export API job per workspace, two day expiry for completed jobs, two years of data availability, and 200 conversations per cloud storage file. No PostgreSQL version specific behavior is claimed, because the COPY page opened is an older PostgreSQL version.

Source

Facts verified 2026-10-31. Open flags are listed in the section above.

This page explains how the process works and what the official rules say. It is general information, not legal advice. For a dispute about your specific situation, talk to your state motor vehicle agency or court.

Keep Exploring

Use the Workflow Library to browse more guides, comparisons, and integration examples to continue your evaluation.