Data export and switching

This page is published by ZeeDo GmbH ("ZeeDo"). Here, "you" and "the Customer" mean the business whose organisation is on ZeeDo, as the Terms of Service define it. The rights described here apply on every plan, Free included.

1. What this page is

This page gives the information that the EU Data Act (Regulation (EU) 2023/2854) asks a provider of a data processing service to give its customers:

• how to export your data and switch to another provider or to your own systems, with the methods, formats and known limits, and the register of data structures and formats (Article 26);
• where ZeeDo's infrastructure is, and how ZeeDo protects data held in the EU against governmental access from outside the EU that would conflict with EU law (Article 28);
• what switching costs (Article 29).

The contract terms are in section 18 of the Terms of Service and section 10 of the Data Processing Addendum. This page explains them; where they differ from it, those sections apply. ZeeDo updates this page when the facts it describes change, and the date above shows the version in force.

2. Exporting your data at any time

While an organisation is active, and while it is read-only until day 60 of the end-of-service clock, an Owner or Admin can export its data as one archive signed by ZeeDo. The archive is produced within 24 hours and can be downloaded for seven days.

In the product. Open Settings → Export and choose Export everything. The page shows when the archive is ready and gives its download link for seven days. Each time you press it, the link leads to a download address that works for 15 minutes.

Through the public API. On the Pro, Business and Enterprise plans, an API key with admin scope can do the same: POST /v1/privacy/export with an empty body requests the archive, GET /v1/privacy/exports/{id} reads its state, and GET /v1/privacy/exports/{id}/download downloads it. On Free and Starter, the export is made in the product (section 6).

How often. You can export as often as you like. While one export of the whole organisation is being written, a new request returns that export; once it is written, you can request another.

One person's data. Settings → Export can also export only the rows that name one person, for example to answer that person's request for access. Such an export holds no files.

Checking the archive. The archive carries its own proof of what it holds:

1. manifest.json lists every other file in the archive with its size, its SHA-256 hash and, for a file of rows, the number of rows.
2. manifest.jws is a detached JSON Web Signature (RFC 7515, Appendix F) made with the ES256 algorithm over manifest.json exactly as stored. Its header names the signing key by its kid.
3. Check the signature against ZeeDo's key set: the public keys that verify ZeeDo's signatures, in JSON Web Key format (RFC 7517). support@zeedo.cloud sends it on request, and ZeeDo will also publish it at a public address named on this page. Ask for it when you download an archive and keep it with the archive, because ZeeDo changes its signing keys from time to time. Then check each file's SHA-256 hash against the manifest. Any standard library for JSON Web Signatures can do this; you need no ZeeDo software.

3. What can be exported, and in which formats

Exportable data. Everything the Customer and its bots put into or create in the service is exportable data, with its metadata:

• (a) in the signed archive: the organisation's records in every part of the service, one file per table in JSON Lines (among them bots and their settings, runs and steps, conversations, the board, approvals and standing approvals, automations, the metadata of connections and files, usage, cost and billing records, and members and roles); each workspace's memory (episodes, summaries, facts and relations, procedures and notes) and traces; the organisation's complete audit log as CSV; and a manifest listing every file with its SHA-256 hash, signed by ZeeDo;
• (b) the files bots made: each can be downloaded in the product and, on paid plans, through the public API; ZeeDo will add them to the archive;
• (c) screen recordings, while they are kept: they can be watched in the product; ZeeDo will make them exportable;
• (d) other content of a workspace machine's disk: ZeeDo will make it exportable.

Not exported, and why: the values of stored credentials, provider keys and sealed keys, and the state of browser sessions, because whoever held them could act in the Customer's accounts: the service hands out no provider key, sealed key or browser session, and a stored credential only to an Owner or Admin who reveals it in the product after re-authenticating (the Customer holds the originals); the identifiers the sign-in provider gives people; the binary model context inside run checkpoints (the checkpoints' records are exported); ZeeDo's internal notes, staff identities and detection signals about abuse and suspensions (what the Customer was told is exported); and the memory image of a running machine. Also not exported: the data section 6 lists under "Also left out of the archive".

Formats: a tar archive of UTF-8 JSON Lines and CSV (RFC 4180) files, with a manifest in JSON and a detached JWS signature (ES256) that ZeeDo's key set verifies, which ZeeDo sends on request and will publish; files in their original format.

4. The register of data structures and formats

The archive is one tar file in the POSIX ustar format. It is not compressed. It is laid out as follows.

<workspace> is the workspace's identifier. A workspace that was deleted but whose data is still within its retention period is included.

Large files. A file of rows that grows past 8 MiB continues in further files numbered before the extension, for example runs/run_steps.part0002.jsonl and runs/run_steps.part0003.jsonl. Read the parts in order. Each part of the audit log's CSV starts with the header row. A table with no rows is still a file: a JSON Lines file with no lines, or the audit log's CSV with only its header row.

JSON Lines. Each line is one JSON object (RFC 8259) for one row of a table, in UTF-8. Its keys are the database's column names, and its values are as the database writes them in JSON: times, for example, in ISO 8601 with their offset from UTC. Large integers are written with all their digits, so read them with a parser that keeps 64-bit integers exact. A column that is not exported (section 3) is left out of the object.

CSV. The audit log follows RFC 4180: fields are separated by commas, a field that holds a comma, a double quote or a line break is enclosed in double quotes, and each record ends with CRLF. The header row names the columns. A field that begins with =, +, -, @, a tab or a carriage return is written with a leading apostrophe ('), so that a spreadsheet program does not run it as a formula. Remove that apostrophe to get the value as stored.

The manifest. manifest.json holds version (now 1), export_id, org_id, scope (organisation, or data_subject for one person's data), requested_at, created_at, members (for each file: path, bytes, sha256, rows where the file holds rows, and group, the part of the service it belongs to) and totals (members, bytes, rows). The header of manifest.jws holds alg (ES256), kid (the RFC 7638 thumbprint of the signing key) and typ (zeedo-export-manifest+jws).

Standards used. JSON (RFC 8259), JSON Lines, CSV (RFC 4180), the POSIX ustar tar format, JSON Web Signature (RFC 7515), JSON Web Key (RFC 7517) and the ES256 algorithm (RFC 7518).

ZeeDo will publish the full list of tables and their columns on this page. Until then, support@zeedo.cloud answers questions about any file or field.

5. Switching to another provider or to your own systems

You can ask at any time to switch to another provider, to move your data to your own systems, or to have your data erased. Section 18 of the Terms of Service sets out the steps. In short:

1. Your request. Send it in text form, for example by email, to support@zeedo.cloud. Say whether you will switch to another provider (and which one, with the details the switch needs), move to your own systems, or want erasure. If you do not know yet, tell ZeeDo in text form by the end of the notice period. If you have not chosen by then, ZeeDo treats your request as one for erasure: the contract ends at the end of the notice period, and you can still export your data until day 60 of the end-of-service clock. ZeeDo confirms each request to the organisation's Owners in text form, with the date on which the notice period ends, so that the Owners learn of each request and can tell ZeeDo if the organisation did not make it.
2. The notice period. It runs to the end of your current monthly billing period. On yearly billing, it runs to the next monthly anniversary of your subscription. It is never longer than two months. On Free, which has no billing period, it ends at the end of the calendar month in which ZeeDo receives your request.
3. The transitional period. It follows the notice period and lasts up to 30 days. The service continues in full: your bots keep working and your plan stays as it was. You can end the transitional period early once your switch is complete, and you can extend it once, for a period you choose, by telling ZeeDo before it ends. If 30 days are technically not possible, ZeeDo tells you so within 14 working days of your request, with its reasons and an alternative period of no more than seven months, and keeps the service running throughout.
4. The retrieval period. When the transitional period ends, the end-of-service clock starts, and its read-only days are your retrieval period. Day 0 is end of service. Days 0 to 60: the organisation is read-only; bots are paused and no new runs start; reads, exports and downloads work, and the Customer may reactivate by subscribing again. Day 60: access and export end, and ZeeDo sends a deletion notice to the Owners. Days 60 to 90: the data is held but not accessible; the Customer may still reactivate by writing to support@zeedo.cloud.
5. Erasure. Day 90: ZeeDo deletes the organisation's data from its live systems. Within 30 days after deletion: it is purged from backups.

If you choose erasure instead of switching, there is no transitional period: the contract ends at the end of the notice period, and the end-of-service clock starts then. You can also delete your organisation yourself at any time in Settings. Deletion then starts at once, and backups are purged within 30 days. Deleted data cannot be restored, so export what you need first.

When the contract ends. The contract ends when your switch is complete, or, if you chose erasure, at the end of the notice period. ZeeDo tells you when it has ended.

What is kept after deletion. Some records are kept for the periods the law requires or allows, such as audit and consent records, invoices, and the record of which version of the terms you accepted. The Privacy Policy (section 6) and the Data Processing Addendum (Annex 4) list each one with its period.

What ZeeDo does to help. During the transitional period, ZeeDo gives reasonable assistance with the switch. It:

• keeps the service running in full and acts with due care to keep your business running;
• keeps a high level of security for your data while it is transferred and until the retrieval period ends;
• answers your questions about the archive, its files and its fields, and, with your consent, the questions of the provider you switch to;
• tells you of any risk it knows of to the continuity of your service or your data during the switch.

ZeeDo has no tool that sends the archive directly to another provider. You download it and load it into the new provider's systems, or your own.

6. Known limits

These are the restrictions and technical limits ZeeDo knows of:

• Files. The files bots made can be downloaded one by one in the product, and through the public API on paid plans. They are not yet in the archive in a form you can open: the archive's files/ folder holds copies of the objects ZeeDo stores for your organisation in ZeeDo's encrypted storage format, which cannot be opened outside ZeeDo. These objects include the bodies of files, the files people hand bots, the full text of each raw memory episode, and working data of runs too large to keep in the database. The archive holds each file's record (its name, type, size and hash) in plain form, and each raw episode's summary; a raw episode's full text is kept for at most 90 days.
• Screen recordings. They can be watched in the product while they are kept (14 days, unless a Business or Enterprise plan keeps them longer). They cannot be exported yet.
• A machine's disk. Content of a workspace machine's disk other than the files described above cannot be exported yet.
• Size. The archive is one file of at most about 55 GiB. A larger archive is refused. If your organisation's data approaches this size, write to support@zeedo.cloud before you request a switch, so that ZeeDo can plan the transfer with you.
• Credentials and keys. The values of stored credentials, provider keys and sealed keys, and the state of browser sessions, are not exported, so that no one who reaches an account or holds an archive can take them. You hold the originals. An Owner or Admin can reveal one stored credential at a time in the product after re-authenticating, and each reveal is recorded in the audit log.
• Also left out of the archive: the vectors ZeeDo computes from memory text and from tool descriptions to search them (the archive holds the text they were computed from, and names the model that computed the memory vectors, so they can be computed again); the amounts of included AI usage in money (the archive shows the share used and the dates); ZeeDo's own costs; the payment provider's raw event records (their identifiers, types and states are exported, and so are the invoice records); the addresses of browser push subscriptions and the signing secrets of webhooks, which work as passwords; unsent drafts of forms, which expire on their own; people's own display choices, such as the bots they pinned and the alerts they marked as read; records of sign-in sessions and of sign-ins in progress, and the event log the sign-in provider sends ZeeDo; and ZeeDo's internal bookkeeping, such as work queues, delivery logs, API answers kept 24 hours for retries, measurements of machine start-ups and the positions of its own jobs, which holds nothing beyond what the archive already holds.
• The API. Free has no API keys, and Starter keys are read-only. On those plans, exports are made in the product.
• Moving data in. ZeeDo offers no import of an export from another provider. Your bots work with your data where it is, through the apps and accounts you connect, and people can hand bots files.

7. Charges

• ZeeDo charges nothing for switching, for exports or for downloading them, on any plan.
• Plan fees run as usual until the contract ends. On monthly billing, the days of the transitional period are charged pro rata to the monthly fee. If you turned on extra usage of ZeeDo's model, what you use is charged as usual.
• On monthly billing, ending the contract costs nothing more.
• On yearly billing, ending early costs only the yearly discount: each month that has begun before the contract ends is charged at the monthly price, and the rest of the prepayment is refunded. If those months, at the monthly price, reach the yearly fee, nothing is refunded and nothing more is charged.
• ZeeDo charges no other early termination fee. An Enterprise order form may agree a term and an early termination fee; if it does, the order form states it before it is signed.
• The plan fees and add-on prices are in section 14 of the Terms of Service.
• Apart from the limits in section 6, ZeeDo knows of no part of its service for which switching is highly complex or costly, or cannot be done without significant interference with your data, digital assets or service architecture.

8. Where the infrastructure is, and who could reach it

8.1 Where

Customer data is stored and processed in the EU (France, Germany and Ireland). Bot machines, ZeeDo's own embedding and reranking models, the control-plane server and the primary file storage run at Scaleway in its Paris region (fr-par), France; a copy of the file storage is kept at OVH in Limburg, Germany; the database (Neon), the workflow service (Temporal Cloud), key management (AWS KMS) and transactional email (Amazon SES) run in Amazon Web Services' Frankfurt region (eu-central-1), Germany; the web application's functions run on Vercel in Frankfurt (fra1), Germany; and traces are kept by Langfuse in its EU region, in Ireland.

The exceptions:

• ZeeDo's model. For an organisation of ZeeDo's EU region, model requests go only through OpenRouter's EU endpoint and are processed in the EU, except the reading of the rules people set for a bot and the check of what a control a bot is about to press would do, which may be served from the United States unless the organisation keeps every model check in the EU.
• Sign-in. Members' sign-in data is processed by WorkOS in the United States.
• Access from the United States. Langfuse's group gives support from the United States. OpenRouter is a company in the United States, and several providers that process data in the EU are, or belong to, companies in the United States that may access it from there. Section 6.4 of the Data Processing Addendum names them.
• Billing. Billing data is processed by Stripe in Ireland, and Stripe's group also processes it in the United States.
• Delivery. The web application's pages and responses pass through Vercel's global edge network, through the edge location nearest the user.
• Your choices. Your bots send data where you direct them: to the apps and websites they work in and the people they contact. With your own model key (BYOK), requests go to the provider you chose.

Every provider and its location is on ZeeDo's sub-processor list.

The infrastructure in France, Germany and Ireland is subject to the law of the EU and of those countries. Some of ZeeDo's providers belong to groups based outside the EU, for example in the United States, whose law can require them to disclose data under their control.

8.2 How ZeeDo protects data held in the EU against unlawful governmental access

Technical measures. Your data is held in the EU sites listed above, and it travels between ZeeDo's services and its providers over TLS. Objects derived from your content, such as snapshots, screen recordings, files and memory texts, are encrypted by ZeeDo before they are written to storage, under data keys that are themselves encrypted under a key held in AWS KMS in Frankfurt. Export archives, which you download, are not encrypted this way. Stored credentials and model-provider keys are encrypted in the Member's browser, to a key held in AWS KMS in Frankfurt, before they reach ZeeDo. The database is encrypted at rest by its provider. Access to ZeeDo's production systems is limited to the persons ZeeDo authorises to operate the service.

Contractual measures. ZeeDo's contracts with its providers outside the EEA, or with access from outside it, include the Standard Contractual Clauses of Commission Implementing Decision (EU) 2021/914. Under clause 15 of those clauses, a provider that receives a legally binding request from a public authority for data transferred under them must notify ZeeDo promptly where its law allows, review whether the request is lawful, and challenge it where, after careful assessment, it finds reasonable grounds to consider it unlawful. Those clauses cover personal data. ZeeDo holds non-personal data in the same systems, under the same technical measures.

ZeeDo's own conduct. ZeeDo answers a governmental request for customer data only where EU or member-state law obliges it to. It checks that the request is lawful, discloses no more than the law requires, and tells the Customer of the request unless the law forbids it.

9. Contact

Exports and switching: support@zeedo.cloud. Data protection: privacy@zeedo.cloud.

By post: ZeeDo GmbH, c/o Ramzy J A Abushaaban, Elsa-Neumann-Straße 53, 13629 Berlin, Germany.