Data Act: switching provider, formats and data location
In force from: 18 October 2026
This page gathers the information that Exelab SRL makes public, as the provider of the plugsync service ("Service"), under Regulation (EU) 2023/2854 ("Data Act"): how to take your data to another provider or to your own systems, in which formats and through which interfaces the data is exported, where it is stored and how it is protected.
The page describes the Service as it is on the date shown at the top. Every version stays available in the archive. The relationship between Exelab and the Customer remains governed by theTerms of Service.
1. Switching to another provider
1.1 What you can take with you
The Customer can obtain a copy of what its organization keeps on the Service: connector configurations, plugins, record mappings, sync history and the other categories listed in theregister of formats. The copy is a single package, covering either the whole organization or one connector.
Synchronized records are not kept on the Service as an archive: they stay in the Customer's HubSpot portal and in the systems the Customer has connected, and switching does not affect them.
1.2 Procedure
- Request the export. From the dashboard, under Settings > Organization > Data export, or through the programming interface (
POST /api/data-exports). Organization owners and organization API keys can do this; other members cannot. - Download the package. The package is prepared in the background. When it is ready it can be downloaded from the dashboard or through a short-lived signed link, which can be requested again for as long as the package exists.
- Take the data to its destination. The package uses open, documented formats (section 2) that common tools can read. Loading the data at the new provider or into your own systems is up to the Customer.
- Close the organization. An owner can request the closure of the organization from the same settings page. If the organization is tied to a commercial agreement with Exelab, the closure is arranged with Exelab by writing tosupport@plugsync.com.
The full procedure, with the responses of the interface and examples, is in thedata export reference page.
1.3 Timing
- How long the package takes to prepare depends on the amount of data in the organization. The status of the export is visible in the dashboard and through the programming interface.
- A ready package can be downloaded for 7 days, then it is deleted. A new export can be requested, one at a time for the same scope (the whole organization or one connector) and up to 10 within 24 hours. For an organization being closed, until the recovery period expires.
- A recovery period of 30 days runs from the request to close the organization: connectors stop immediately, exports remain available and an owner can cancel the closure. Once the period has passed, the organization's data is deleted (paragraph 1.6).
- The notice for termination and the period the Customer has to export data after the contract ends are those in section 11 of the Terms of Service.
1.4 Costs
Data export and organization closure are functions of the Service, available to every organization regardless of plan. The price list (in Italian) sets no fee for requesting an export, downloading the package or closing the organization. Amounts due for the subscription remain governed by the Terms of Service.
1.5 Known limits
- Credentials. Credentials saved on the Service (tokens, API keys, passwords, signing secrets) are not exported: the package carries only their names. They have to be configured again at the new destination.
- Secrets written by hand. The package is a faithful copy: nothing in it is masked. A secret the Customer wrote directly into a configuration, into the code of a plugin or into the data sent to the Service, instead of saving it as a credential, is in the package as it is. The package should be kept like a credential.
- Format of configurations and plugins. Connector configurations are JSON documents in the Service's own format, described in the public documentation. Plugin code is exported as TypeScript source and as a JavaScript bundle, written for the Service's plugin execution environment. Another provider does not run them as they are: they need to be adapted.
- A snapshot in time. The package is prepared while syncs keep running: records written during preparation may or may not be included.
- Data already deleted. The package contains what the Service keeps at the moment it is prepared. Data already deleted at the end of its retention period is not included.
- No direct transfer. The Service does not send data to another provider's systems: switching happens through the package.
- Other exclusions. The full list of what the package does not contain, with the reason, is in paragraph 2.3 and in every package.
1.6 Deletion of data
Once the recovery period has passed, the organization's data is deleted from the Service: connectors, configurations, credentials, plugins, record mappings, history, exported files, export packages, and users left without any other organization.
After deletion, the technical copies that cannot be deleted for a single organization remain for a limited time: database backup and recovery copies, from which deleted data stays recoverable for at most 35 days, and the platform's technical logs, kept for one month. The records Exelab keeps as evidence or because the law requires it also remain: the acceptance of the contractual documents, the record of the deletion itself, the communications sent to the owners and the billing documents. For account data the Privacy Policy applies.
2. Register of formats and interfaces
2.1 Package format
- The package is a ZIP archive. It uses the ZIP64 extensions when needed (a file or a package over 4 GB).
- Data is in JSON Lines files (
.jsonl): UTF-8 encoding, one JSON object per line. Dates are in ISO 8601 format, in UTC. manifest.jsonis the index of the package: it lists the categories, the files with their record counts and the exclusions.- The format has a version number, carried in the manifest:
format_version1.
2.2 Exportable data categories
| Category | Files in the package | Content |
|---|---|---|
connectors | connectors.jsonl | The organization's connectors. |
configuration | configuration/versions.jsonlconfiguration/drafts.jsonl | Every published version of each connector's configuration and the draft in progress. |
plugins | plugins/plugins.jsonlplugins/<plugin name>/source.tsplugins/<plugin name>/bundle.js | The organization's plugins, with the TypeScript source code and the JavaScript bundle. |
plugin_storage | plugins/storage.jsonl | The data plugins have saved in their key-value storage. |
identity_mappings | identity_mappings.jsonl | The mappings between a record's identifier in the Customer's system and the HubSpot object. |
sync_history | sync_history.jsonl | The outcome of every synchronized event. |
recorded_payloads | recorded_payloads.jsonl | The contents of events recorded while recording is turned on for the connector. |
agent_conversations | agent_conversations.jsonl | The conversations with the configuration assistant. |
source_samples | source_samples.jsonl | The sample events collected from sources. |
conflicts | conflicts.jsonl | The conflicts detected between systems and how they were resolved. |
bulk_imports | bulk_imports/jobs.jsonlbulk_imports/rows.jsonl | Bulk imports and the outcome of their rows. |
verifications | verifications/jobs.jsonlverifications/rows.jsonl | The alignment checks between systems and the differences found. |
file_sources | file_sources/files.jsonlfile_sources/discarded_rows.jsonl | The reports of the files processed by file sources and the sample of discarded rows. |
usage | usage/monthly_events.jsonlusage/daily_counters.jsonl | Usage counts: events per month and results per day. |
Every category is always present in the package: a file with no records is an empty file. The fields of each file are described one by one in thedata export reference page.
2.3 What the package does not contain
Every package declares its own exclusions in the manifest, under the same names, with the reason.
| Name | What is left out | Why |
|---|---|---|
credentials | The credentials saved on the Service: connector credentials, event source secrets, organization API keys. | They are secrets: they are stored encrypted and do not leave the Service. The configuration refers to them by name, and the name is exported. |
export_files | The files connectors produce with scheduled exports. | They can already be downloaded, file by file, from the connector's Exports tab. |
account_data | The account data of the people in the organization: members, invitations, billing. | It describes the account, not the data processed by connectors, and is managed from the dashboard settings. |
discarded_rows_beyond_sample | The rows discarded from a file beyond the first 20. | The Service keeps a sample of each file's discarded rows, not all of them. |
data_past_retention | Records and contents already deleted at the end of their retention period. | Data is deleted periodically when its retention period ends. Whatever the Service still keeps at the time of the export is included. |
processing_state | Working data of the processing, such as the copy of each event as it was received. | It is what the Service holds while it works. The outcome of every event is in sync_history.jsonl. |
platform_logs_and_backups | The platform's logs and backups. | They are not kept per organization, so an export cannot contain them. A request about them goes through support. |
2.4 Interfaces
| Interface | What it is for | Documentation |
|---|---|---|
| Data export | Requesting an export, following its status and downloading the package, over HTTPS with JSON responses (/api/data-exports) or from the dashboard. | Data export |
| Event API | Sending the events of your systems to the Service, over HTTPS in JSON format. | Event API |
| Connector configuration | The JSON format the exported configurations are written in. | Config v3 and Event flow manifests |
| Plugins | The contract under which the Service runs the exported plugin code. | Plugins |
| Command line | Managing connectors, configurations and plugins from a terminal. | CLI |
The documentation of the interfaces is public and in English, atdocs.plugsync.com.
2.5 How the register is updated
When a change to the package requires whoever reads it to adapt, the format_version number changes. When the categories, the exclusions or the format change, this page is published in a new version and the previous one stays in the archive.
3. Data location and protection measures
3.1 Where data is stored
The Service is hosted on the cloud infrastructure of Amazon Web Services, in theeu-central-1 (Frankfurt, Germany) region, in the European Union. The databases, the file storage, the export packages, the logs and the backup copies are located there. Exelab SRL, which operates the Service, is an Italian company.
3.2 Suppliers
The suppliers that process data on behalf of customers are listed, with the data they receive, on thesub-processors page (in Italian). As regards data location:
- Amazon Web Services hosts the Service in the region stated above.
- Sentry and PostHog receive the data stated in that list on infrastructure in the European Union.
- Anthropic provides the model used by the configuration assistant and receives only what the user sends to the assistant and what the assistant reads in order to answer. This processing may take place outside the European Union. Those who do not use the assistant send no data to Anthropic.
Amazon Web Services, Sentry, PostHog and Anthropic belong to groups based in the United States.
3.3 Data in the Customer's systems
The Service writes records to the Customer's HubSpot portal and to the systems the Customer connects. Where that data is located depends on the Customer's contracts with HubSpot and with the suppliers of those systems, not on the Service.
3.4 Technical protection measures
- Location. Customer data is stored in the European Union region stated above, and so are its backup copies.
- Encryption at rest. The databases and the file storage are encrypted. The keys for this encryption are managed by the infrastructure services.
- Encryption of credentials. The credentials the Customer saves on the Service are also encrypted by the application before being stored, and do not appear in exports.
- Encryption in transit. The dashboard and the programming interfaces can be reached only over HTTPS; HTTP requests are redirected.
- Limited retention. Data is deleted when its retention period ends and, when the organization is closed, once the recovery period has passed.
4. Contacts
For switching to another provider and for data export:support@plugsync.com. For questions about the processing of personal data: privacy@plugsync.com.