Data export

A copy of everything your organization holds on plugsync, as one ZIP package: connector configurations, plugins and their storage, identity mappings, sync history, recorded payloads, agent conversations, event source samples, conflicts, the outcomes of bulk imports and verifications, the reports of file sources with the rows they discarded, and usage figures. Use it to keep your own archive, to audit what the platform stores about your records, or to take your data with you. What a package leaves out is listed in its manifest, with the reason (see What is not in the package).

An export is asked for, prepared in the background, and then downloaded through a signed link:

1. POST /api/data-exports answers 202 with the export and its id.
2. GET /api/data-exports/{id} shows its status. Preparation usually starts within a minute; how long it takes depends on how much data the organization holds.
3. Once the status is completed, GET /api/data-exports/{id}/download returns a signed link to the ZIP.

The same flow is in the dashboard under Settings > Organization > Data export.

Who can export

The owners of the organization, and the organization’s API keys. A member gets 403. An export, like a connector, belongs to one organization: the id of an export or of a connector of another organization answers 404.

A package holds payloads, plugin code and agent conversations, exactly as you wrote or sent them (see Secrets you wrote yourself). Treat the package, and a key that can ask for one, like a credential.

Scope

One export per scope can be in preparation at a time: asking again while one is queued or running answers 409 data_export_in_progress with the export_id of the one in progress. An organization can ask for 10 exports per 24 hours; past that the answer is 429 data_export_limit_reached.

The API error catalog collects these codes with the errors of every other public route.

API

All routes take Authorization: Bearer <token or API key>.

POST /api/data-exports

curl -X POST https://app.plugsync.com/api/data-exports \
  -H "Authorization: Bearer $PLUGSYNC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

{
  "id": "5b0e6a52-7a0f-4d53-9c1e-2f4f0a1f7c11",
  "scope": "organization",
  "connector_id": null,
  "status": "queued",
  "requested_by": "api-key:backup",
  "created_at": "2026-10-08T09:00:00Z",
  "completed_at": null,
  "expires_at": null,
  "size_bytes": null,
  "error": null,
  "categories": []
}

GET /api/data-exports and GET /api/data-exports/{id}

The list returns the 20 most recent exports of the organization, newest first, as {"exports": [...]}. Each has the shape above.

GET /api/data-exports/{id}/download

{
  "url": "https://...",
  "filename": "plugsync-export-20261008-5b0e6a52.zip",
  "expires_in_seconds": 300
}

url is a signed link valid for 5 minutes: fetch it right away, without the Authorization header. Ask for a new link whenever you need one, for as long as the package exists.

How long a package is kept

A package can be downloaded for 7 days after it is ready, then it is deleted and the export shows as expired.

Deleting a connector expires every package of its organization, because a package may hold that connector’s data: the exports show as expired and their download answers 410 as soon as the connector is deleted, and the files are removed right after. An export that was still being prepared at that moment is prepared again without the deleted connector, so it can take longer than usual; a package requested after the deletion is not affected.

Closing the organization deletes the packages with everything else at the end of the recovery period; until then exports can still be requested and downloaded. At the end of the period an export still in preparation fails with organization_closed.

A package is a snapshot taken while syncs keep running. Each file is read once, front to back; records written while it is being read may or may not be in it.

The package

manifest.json
connectors.jsonl
configuration/versions.jsonl
configuration/drafts.jsonl
plugins/plugins.jsonl
plugins/storage.jsonl
plugins/<plugin name>/source.ts
plugins/<plugin name>/bundle.js
identity_mappings.jsonl
sync_history.jsonl
recorded_payloads.jsonl
agent_conversations.jsonl
source_samples.jsonl
conflicts.jsonl
bulk_imports/jobs.jsonl
bulk_imports/rows.jsonl
verifications/jobs.jsonl
verifications/rows.jsonl
file_sources/files.jsonl
file_sources/discarded_rows.jsonl
usage/monthly_events.jsonl
usage/daily_counters.jsonl

Every category is always present: a file with no records is an empty file, and its entry in the manifest says "records": 0.

.jsonl files are JSON Lines : UTF-8, one JSON object per line, no enclosing array. Read them line by line; the larger files (identity_mappings.jsonl, sync_history.jsonl, bulk_imports/rows.jsonl) can hold millions of lines. Timestamps are ISO 8601 in UTC. A field with no value is null.

The ZIP uses the ZIP64 extensions when it needs them (a file over 4 GB, or a package over 4 GB). Current versions of unzip, 7-Zip, Python’s zipfile and the archive tools of macOS and Windows read it.

manifest.json

The index of the package. Start here.

{
  "format_version": 1,
  "export_id": "5b0e6a52-7a0f-4d53-9c1e-2f4f0a1f7c11",
  "organization_id": "0d0c9a3e-3a67-4b0e-b1a5-1f1f6a2b9d10",
  "scope": "organization",
  "connector_ids": ["9c7f0b5e-0a55-4b71-8f3b-6f1c2b7a4e02"],
  "generated_at": "2026-10-08T09:01:12.412301+00:00",
  "categories": [
    {
      "name": "identity_mappings",
      "files": [
        { "path": "identity_mappings.jsonl", "format": "jsonl", "records": 18304 }
      ]
    },
    {
      "name": "plugins",
      "files": [
        { "path": "plugins/plugins.jsonl", "format": "jsonl", "records": 1 },
        { "path": "plugins/bank-check/source.ts", "format": "typescript", "plugin": "bank-check", "bytes": 2210 },
        { "path": "plugins/bank-check/bundle.js", "format": "javascript", "plugin": "bank-check", "bytes": 48113 }
      ]
    }
  ],
  "exclusions": [
    {
      "name": "credentials",
      "description": "The credentials saved on the platform: connector credentials (OAuth tokens, API keys, passwords), the secrets of the event sources (such as webhook signing secrets) and the API keys of the organization.",
      "reason": "They are secrets. They are stored encrypted and never leave the platform; the configuration refers to them by name, and the name is exported."
    }
  ]
}

connectors.jsonl

One line per connector.

The credentials of a connector are never exported: the tokens, API keys and passwords you saved for it are not in the package in any form.

configuration/versions.jsonl

One line per published version of each connector, the full history.

configuration/drafts.jsonl

One line per connector: the draft being edited, published or not.

plugins/plugins.jsonl and the code files

One line per plugin of the organization.

The code is next to it: plugins/<plugin name>/source.ts is the TypeScript you pushed, plugins/<plugin name>/bundle.js the bundle built from it. Take the exact paths from the manifest: characters that are not letters, digits, ., _ or - are replaced with _ in the folder name.

plugins/storage.jsonl

One line per key in the key-value store of a plugin on a connector (see the store capability).

identity_mappings.jsonl

One line per record the platform has linked: the id in your system and the id of the HubSpot object.

Other fields can be present on some lines (for example the timestamps used to resolve conflicts on bidirectional connectors).

sync_history.jsonl

One line per synced record, as listed by GET /api/connectors/{connector_id}/sync-events. Lines are in no particular order: sort on created_at if you need one.

Only the history still kept is exported: rows and payloads already removed by data retention are not in the package.

recorded_payloads.jsonl

One line per event archived by record mode, with the payload exactly as it was received. Empty when record mode was never enabled.

agent_conversations.jsonl

One line per conversation with the AI agent.

A connector export holds only the conversations about that connector.

source_samples.jsonl

One line per event source: the last payload that source received, the one the mapping editor shows as a sample. A source that has received nothing yet has no line.

conflicts.jsonl

One line per conflict detected on a bidirectional connector (see Loop prevention and conflicts).

bulk_imports/jobs.jsonl and bulk_imports/rows.jsonl

jobs.jsonl has one line per bulk import, including the ones a file source started.

rows.jsonl has one line per record of an import whose outcome was kept.

verifications/jobs.jsonl and verifications/rows.jsonl

jobs.jsonl has one line per verification: a comparison between a batch of your records and what is on HubSpot.

rows.jsonl has one line per record whose outcome was kept.

file_sources/files.jsonl and file_sources/discarded_rows.jsonl

files.jsonl has one line per file a file source has read (see Event sources), with the report of its last processing. The files themselves are not in the package: they are on your server.

A field the report of a file does not carry is null.

discarded_rows.jsonl has one line per discarded row the platform has kept. It keeps the first 20 discarded rows of each file, not all of them: rows_discarded in files.jsonl is the full count. A raw longer than 2,000 characters is cut at that length. The rows are kept for the files the source still tracks: a processed file that has left the remote directory stops being tracked after 90 days, or sooner once the source tracks more than 1,000 files, and its rows go with it. When a file is processed again, the rows it discards replace the ones kept before.

usage/monthly_events.jsonl and usage/daily_counters.jsonl

monthly_events.jsonl has one line per billing month: the events counted against the plan of the organization. It is empty in a connector export.

daily_counters.jsonl has one line per connector, day, outcome, entity and direction: how many records ended with that outcome that day. These are the figures behind the charts of the connector’s overview.

What is not in the package

Every package says this itself: exclusions in manifest.json carries the same entries under the same names, each with a description and a reason.

The one trace of a member in a package is the email recorded where that member acted: published_by and updated_by in the configuration files, resolved_by in the conflicts.

Secrets you wrote yourself

The package is a faithful copy: nothing in it is masked or rewritten. The platform keeps the credentials you saved out of it, but it cannot tell a secret from any other text in content you wrote or sent. If one of these holds a secret, the package holds it too:

To keep a secret out of future packages, save it as a credential and refer to it from the configuration.

Reading a package

import json, zipfile
 
with zipfile.ZipFile("plugsync-export-20261008-5b0e6a52.zip") as package:
    manifest = json.loads(package.read("manifest.json"))
    for category in manifest["categories"]:
        for entry in category["files"]:
            print(entry["path"], entry.get("records", entry.get("bytes")))
 
    with package.open("identity_mappings.jsonl") as lines:
        for line in lines:
            mapping = json.loads(line)
            ...