Exporting your data and switching provider

Art. 26

Export methods and formats

A workspace admin exports all the data at once, without asking support.

• In the application: Team → Danger zone → Export data (JSON).
• Through the API: GET /api/v1/workspace/export, authenticated as a workspace admin.
• Format: one UTF-8 JSON file (application/json; charset=utf-8), in the datavault-export/2 format, described by a public JSON Schema.
• The export is free of charge.

The file has every section in the format register, which also lists what is left out and why.

Other machine-readable formats

Parts of the data also come out in other open formats, through the API:

• Public read-only REST API, with its published OpenAPI contract

  Standard: OpenAPI 3.1 · Type: application/json

  See page

• Each dataset's rules and contract as dbt tests

  Standard: dbt (schema.yml) · Type: application/yaml

  • GET /api/v1/datasets/{dataset_id}/rules.dbt.yml
  • GET /api/v1/datasets/{dataset_id}/contract.dbt.yml

• Each dataset's rules, or the whole workspace's, as SodaCL checks

  Standard: SodaCL · Type: application/yaml

  • GET /api/v1/datasets/{dataset_id}/rules/export
  • GET /api/v1/rules/export

• Each dataset's rules as a Great Expectations suite

  Standard: Great Expectations 1.x (suite JSON) · Type: application/json

  • GET /api/v1/datasets/{dataset_id}/rules/export

• Audit, SLO, dimension, PII, governance and query log tables

  Standard: CSV (RFC 4180) · Type: text/csv

  • GET /api/v1/admin-events/export.csv
  • GET /api/v1/dashboard/slo.csv
  • GET /api/v1/dashboard/dimensions.csv
  • GET /api/v1/dashboard/pii.csv
  • GET /api/v1/governance/scorecard.csv
  • GET /api/v1/catalog/metadata-quality.csv
  • GET /api/v1/cde/dossier.csv
  • GET /api/v1/connections/{connection_id}/query-log/export

• Reports, dataset READMEs, governance evidence and dossiers

  Standard: Markdown, PDF · Type: text/markdown, application/pdf

  • GET /api/v1/reports/{report_id}/export.pdf
  • GET /api/v1/datasets/{dataset_id}/readme.md
  • GET /api/v1/governance/evidence.md
  • GET /api/v1/cde/dossier.md
  • GET /api/v1/compliance/ai-systems/{system_id}/art10.md

Arts. 25 and 26

Format register

The exhaustive list of what the export includes and what it leaves out, with the reason for each exclusion. The register is generated from the BeryX code that builds the export.

Format

datavault-export/2

JSON Schema

Download the JSON Schema (datavault-export-2.schema.json)

Dialect

https://json-schema.org/draft/2020-12/schema

Reasons for exclusion

Each exclusion below refers to one of these reasons.

1. 1.Operational secret: a password, token, key or the encrypted configuration of a connection, channel or integration. It never leaves in clear text in a file; the source credentials belong to the customer, who already has them.
2. 2.Copy of the email of whoever acted, kept for the audit trail. The export identifies the person by the user id on the same row (users section).
3. 3.Recipient emails, encrypted at rest. They are left out of this version of the format; the delivery channels are exported in channel_ids.
4. 4.BeryxTech billing identifiers at Stripe (payments sub-processor).
5. 5.Internal state of the service (session and MFA counters), meaningless outside DataVault.
6. 6.Temporary state that expires on its own (SSO login flows, open sessions, scan progress, questions to the Slack bot awaiting an answer).
7. 7.Derived from data already in the export and regenerable: vector embeddings of the knowledge base entries.
8. 8.Organisation data, which may span several workspaces. The export covers one workspace and carries no data from the others.
9. 9.Internal record of the BeryxTech support team's actions.

Top of the file

The workspace object holds the workspace's own data (table workspaces).

Sections

129 sections, by category. Each is a JSON key with the rows of one workspace table.

Excluded fields

• workspace: stripe_customer_id, stripe_subscription_id (reason 4)
• users: password_hash, mfa_secret_encrypted (reason 1); mfa_last_step, token_version (reason 5)
• api_tokens: token_hash (reason 1)
• support_grants: staff_label (reason 2)
• chat_account_links: token_hash (reason 1)
• connections: config_encrypted (reason 1)
• dataset_public_shares: token_hash, token_encrypted (reason 1)
• domain_public_shares: token_hash, token_encrypted (reason 1)
• remote_profiler_runs: ingest_claim_hash, ingest_token_hash (reason 1)
• contract_proposals: token_hash, token_encrypted (reason 1)
• notification_channels: config_encrypted (reason 1)
• workspace_llm_credentials: key_encrypted (reason 1)
• catalog_integrations: token_encrypted (reason 1)
• dbt_cloud_integrations: secret_encrypted, api_token_encrypted (reason 1)
• git_integrations: token_encrypted (reason 1)
• ticket_integrations: config_encrypted (reason 1)
• pipeline_integrations: credentials_encrypted (reason 1)
• bi_integrations: credentials_encrypted (reason 1)
• openlineage_configs: api_key_encrypted (reason 1)
• mcp_servers: secret_encrypted (reason 1)
• collaboration_integrations: config_encrypted (reason 1)
• report_schedules: recipients_encrypted (reason 3)
• report_public_shares: token_hash, token_encrypted (reason 1)
• assistant_action_requests: requested_by_label, decided_by_label (reason 2)
• admin_events: actor_label (reason 2)

Tables that are not exported

These tables are left out entirely.

Arts. 28 and 32

Jurisdiction and governmental access

Where BeryX's infrastructure runs, under which jurisdiction, and which measures protect non-personal data against international governmental access that conflicts with EU law.

Infrastructure

• The application, the database and the processing run on Google Cloud, in the europe-west1 region (Belgium), and backups are kept in Google's EU multi-region. The contract is with Google Cloud EMEA Limited (Ireland).
• The message queue runs on CloudAMQP (84codes AB, Sweden), in the AWS eu-west-1 region (Ireland).
• The Terms of Service are governed by Portuguese law.

What may leave the EU

• Platform logs, with the IP address of each request, are kept in Google Cloud Logging in the global location and may be stored outside the EU.
• Platform secrets are kept in Google Secret Manager, with replicas chosen by Google that may be outside the EU.
• Source code sent to Cloud Build is kept in a bucket in the US multi-region.
• Google support may access from outside the EEA, under standard contractual clauses in Google's data processing agreement.
• Sub-processors that process data outside the European Economic Area: Anthropic, Resend, Stripe, Voyage AI, GitHub, Sentry and Twenty (from 16 November 2026). Each one's purpose, data and transfer mechanism are in the Privacy Policy.
• With AI on, Anthropic (USA) receives metadata and limited samples from the sources and, by default, is the only model provider that receives samples. With AI turned off in the workspace policy, nothing goes to model providers.

Measures against governmental access

• At rest, Google encrypts everything with AES-256 and Google-managed keys. The shared SaaS does not use customer-managed keys (CMEK).
• Source credentials and integration secrets are encrypted by the application (Fernet) before being stored, and the key is kept in another service (Secret Manager).
• Access to the customer's sources is read-only, and BeryX stores metadata, metrics and limited samples.
• The BeryxTech team only enters a workspace with the approval of a customer admin, read-only and for 72 hours at most. The request, the decision and the first access are recorded in the workspace audit trail.
• On the Enterprise plan, the Claude models can run in the customer's own AWS (Amazon Bedrock) or Google Cloud (Vertex AI) account, in a European region.
• Contractual measures and BeryxTech's procedure when an authority of a third country requests access: to be confirmed

Arts. 25 and 29

Switching provider

The switching clauses are in the Terms of Service. In short:

Notice period

2 months to ask to switch to another provider or to your own infrastructure, or only for the data to be erased (legal maximum; to be confirmed).

Transition

Up to 30 days after the notice period, with the service running. If that is technically unfeasible, BeryxTech tells you within 14 working days and the period may go up to 7 months. You can extend it once.

Data retrieval

At least 30 days after the transition (to be confirmed).

Erasure

At the end, BeryxTech permanently erases all the workspace's data. In backups, the data only disappears when they expire.

Switching charges

Until 11 January 2027, at most the direct cost of switching. From 12 January 2027, none, including data egress. The export in the application is free of charge.

Early termination penalties

to be confirmed

End of the contract

When switching is complete and BeryxTech informs you. If you only ask for erasure, at the end of the notice period.