Data Act Transparency

1. What this page is

This page is published by Finalform GmbH, Theodor-Heuss-Str. 106, 26129 Oldenburg, Germany ("Finalform", "we", "us"), the operator of Autopage. It brings together, in one place and kept up to date, the information that Articles 26, 28 and 29 of Regulation (EU) 2023/2854 (the Data Act) require a provider of a data processing service to publish: how switching and porting work, the register of the data structures and formats your export arrives in, which jurisdiction the infrastructure behind each part of the service is subject to, what we do about third-country governmental access, and what switching costs.

It is written for the person who has to plan an exit before signing, so it states the procedure and the facts plainly and in one place. What we publish here we hold ourselves to. Where this page and the Terms of Service ever differ, the Terms govern, because they are the contract. This page is addressed to businesses, since Autopage is offered to businesses only.

2. Jurisdiction of the ICT infrastructure, per service

Article 28(1)(a) asks which jurisdiction the ICT infrastructure deployed for each part of the service is subject to. Autopage runs on five providers, and the table names the contracting entity, the jurisdiction that entity is subject to, and where the infrastructure that serves that part of the product actually sits.

Every fact in this table is taken from our sub-processor list and nothing is added to it. The sub-processor list carries the role of each provider, the categories of data it receives, and the transfer mechanism that applies to it. Where the two ever disagree, follow the sub-processor list: it is the maintained source, and this table is derived from it.

3. Measures against third-country governmental access

Article 28(1)(b) asks for a general description of the technical, organisational and contractual measures we take to prevent third-country governmental access to or transfer of non-personal data held in the Union, where such access or transfer would conflict with Union or Member State law. The measures in place are:

• EU region pinning for data at rest. The managed database and every production service run in the Amsterdam region, so all data that Autopage itself persists is stored in the European Union. A United States processing leg remains for the providers named above, and it is a third-country transfer; the safeguards for it are in the documents named at the end of this section.
• Encryption. Data is encrypted in transit with TLS and encrypted at rest.
• Data minimisation at the boundary.No per-visitor personal data reaches the language model. Direct identifiers are stripped before a prompt is built, and only the customer's brief, baseline page copy and population-level aggregates are sent.
• Tenant isolation in the database. Every tenant-scoped table is isolated at the row level, and the engine runs under a role that cannot read across that boundary.
• A transfer mechanism per recipient. Each third-country recipient is covered either by Standard Contractual Clauses or by a Data Privacy Framework certification, with a transfer impact assessment maintained for the leg regardless of which of the two applies.
• Challenge and notify. We will challenge any governmental access request that conflicts with Union or Member State law, and we will notify the affected customer wherever we are legally permitted to do so.

The recipient-by-recipient analysis, the supplementary-measures register and the residual-risk conclusions are in our transfer impact assessment, which we make available to a customer acting as controller, and to a competent supervisory authority, on request. The recipients, their regions and the transfer mechanism for each are in our published sub-processor list. This page does not repeat that analysis, so that there is one place where it is maintained.

4. Switching and exit

Article 26(a) asks for the procedure. This is what happens, end to end. Section 13 of the Terms of Service, "Switching, data export and exit", is the contractual form of this procedure and carries the same periods; this section describes how it runs in practice.

Making the request. Write to support@autopage.dev from an address on the account, saying that you want to switch or to port your data. No reason is needed and no form has to be filled in. We acknowledge the request and record the date we received it, because the statutory clock runs from there.

The notice period, and the three decisions at the end of it. The notice period is at most two months, and it is shorter wherever we can make it shorter. Before it ends you tell us which of three things you want: to switch to another provider, which you name; to port your data to your own systems; or to have your data erased without porting it anywhere.

The transitional period. Once the notice period ends, the switch is completed within 30 calendar days. If that is technically unfeasible for your account, we tell you so within 14 working days of your request, we explain why, and we propose an alternative period of at most seven months. You may also extend the transitional period once yourself, for as long as you consider appropriate.

What we do while it runs. The contract stays in force for the whole transitional period. We assist with the switch, maintain service continuity so the pages under optimization keep working, tell you about any continuity risk we know of, and keep your data secure throughout. After the transitional period ends, your export stays retrievable for at least a further 30 calendar days, and after that window we erase the exported data along with the rest of the account.

The export itself. All exportable data is provided in a structured, commonly used and machine-readable format, at no charge, as Article 30(5) requires. Section 5 is the register of the data structures and formats it arrives in. Autopage is an application service rather than an infrastructural one, so functional equivalence under Article 30(1) is not part of what is offered; the known restrictions below explain why.

5. Register of data structures, data formats and standards

Article 26(b) asks for a reference to an up-to-date online register of the data structures and the data formats of the exportable data. This section is that register. It is revised whenever the export changes, and it never describes a format the export does not produce.

How to get the export. Ask at support@autopage.dev, or fetch it yourself: a signed-in member of the organization can call https://app.autopage.dev/api/export/<your organization id> and the archive downloads. The organization id is the identifier the export uses internally as the tenant id; they are the same value, so there is no second id to look up. There is no charge either way.

The archive. One gzip-compressed tar file, named autopage-export-<your organization id>-<date>.tar.gz. It holds one file per exported table plus manifest.json. Read manifest.json first: it states what was written, what was withheld and why, and what sits outside a page export altogether. It is written last inside the archive, because the digests in it are only known once the files are finished, and the order of entries inside a tar carries no meaning.

The file format. Newline-delimited JSON, the format a line-by-line reader and a COPY into another database both take without conversion.

• One JSON object per line, UTF-8, terminated with a line feed, no byte order mark.
• Keys are the database column names, in lower snake_case, so the file matches the register below and matches what a plain database dump would give you.
• Timestamps are ISO 8601 in UTC, with milliseconds and a trailing Z.
• Structured columns are nested JSON, never a string containing JSON.
• A null value stays null and keeps its key. A withheld column is absent from every line instead, and manifest.json names it and the reason.
• A table too large to read in one pass arrives as a directory of numbered parts, for example events/part-00001.ndjson. The manifest lists the file names that were actually written, so follow the manifest rather than a naming convention.

What manifest.json contains.

The register, table by table. Fifteen tables hold data for one page. This is what each one is and what the export does with it. The names are the database table names, which are also the file names in the archive.

What sits outside a page export, and where to get it instead. manifest.json lists these with a reason for each. Account and billing records, meaning the organization, its members, its invitations and its subscription, are account data rather than page data; the billing record of account is in Stripe and you reach it from your billing settings. Your own user account, its sessions, its credentials and its security counters are security and integrity data, and a copy of your personal data is a request under Articles 15 and 20 GDPR rather than a page export. The legal acceptance ledger is account-scoped evidence of what was agreed and when, so deleting one page must not erase it; the account holder can ask for it. The shared enrichment cache holds material drawn across customers and has no per-page boundary at all. Platform deletion evidence is cross-customer operational record-keeping.

Standards and common specifications. Article 30(3) requires an export to be compatible with harmonised standards or common specifications for interoperability that the European Commission has published in the central Union repository. No harmonised standard and no common specification exists for application-layer services of this kind at the date of this page, so there is nothing yet for this format to be compatible with. Newline-delimited JSON with a manifest was chosen because it is a widely used, non-proprietary, line-oriented format that a destination provider can read without a tool from us. If a standard or common specification is published for this service type, this section will say how the export relates to it.

6. Charges

Article 29(4) to (6) ask for the fee picture in a dedicated public section. This is it.

Switching is free of charge. There is no switching fee, no export fee and no assistance fee, today and after 2027-01-12, when the Data Act prohibits switching charges outright. We chose not to charge from day one rather than run a cost-based model for the intervening months.

Standard service fees are the plan prices. The Starter and Pro plan prices are those shown on our current published pricing and on the plan cards in your billing settings. All prices are net and exclusive of value-added tax at the applicable statutory rate. Subscriptions are billed monthly or yearly, as booked.

There is no early-termination penalty. Requesting a switch costs nothing. Where you have booked a fixed term that has not yet expired, the fees for that term remain due, and we credit against them the expenses we save by not serving the remainder. That is a contractual balance, not a switching charge, and it does not depend on whether you switch.

7. Known restrictions

Article 26(a) asks for the known technical restrictions to be stated rather than discovered during an exit. There are three.

Retention bounds. Some data is deleted on a schedule and cannot be exported after it is gone. Raw visitor events and their session assignments are retained for 90 days from ingest, and in-app notifications for 30 days. The per-iteration metrics snapshot is the layer designed to outlive the raw events, and it is exported in full. Our data retention policy sets out every category and its period.

Provider trade secrets and protected material are outside the export. Article 2(38) defines exportable data so that it excludes assets protected by intellectual-property rights or constituting a trade secret of the provider, together with data related to the integrity and security of the service. For Autopage that boundary covers the optimization prompts and templates, the engine's internal statistical state and scoring, the enrichment cache, and security data such as API key material and rate-limit counters. It does not cover results: the variants the model generated for you, including the copy itself, are exported in full, as are your briefs, experiments, iterations, metrics, events and session assignments.

Functional equivalence is not offered. Article 30(1) requires a provider to maintain functional equivalence in the destination environment, and recital 86 confines that duty to services providing infrastructural elements. Autopage is an application service, so the duty that applies instead is Article 30(5): on request, all exportable data in a structured, commonly used, machine-readable format. That is what we provide, free of charge.

8. Keeping this page up to date

Article 28(1) requires this information to be kept up to date, so this page is revised whenever a provider, a region or a fee changes, and reviewed at least once a year. The date of the last revision is stated at the top of this page and changes with every revision.

Questions about switching, porting or anything on this page go to support@autopage.dev. We answer in English or German.

Related documents.The Terms of Service are the contract between us and govern where this page and they differ; Section 13 of the Terms, "Switching, data export and exit", is the clause this page describes. The sub-processor list and the data retention policy are published alongside this page and are linked in the footer: the first names every provider, the data it receives and the transfer mechanism for it, and the second carries every retention period in full. The transfer impact assessment, which holds the per-recipient analysis behind the measures described above, is an internal accountability record and is provided on request.