Switching and export

The German version is legally binding.

The Data Act (Regulation (EU) 2023/2854) requires information on how an agency switches to another provider and exports its data (Art 26 and 28). This page gives it for Mailingbid for agencies. The Terms of Use are binding, above all clause 16a; this page summarises them.

Procedure

An owner of your agency may at any time request in text form, sent to kontakt@mailingbid.com, that the agency switch to another provider or to its own systems, or that its exportable data be deleted (switching request, clause 16a.1).

The notice period is one month from receipt of the switching request. Before it ends, you tell us in text form whether you

are switching to another provider, with the details of that provider that are needed for the switch,
are switching to your own systems, or
want your exportable data deleted.

If you tell us nothing by the end of the notice period, this counts as a switch to your own systems.

In cases a and b, a transition period of 30 calendar days begins at the end of the notice period (clause 16a.2). During it we make all exportable data available to you as an export without undue delay, provide reasonable assistance with the switch to you and to third parties you designate, such as the new provider, continue to provide our services under the user agreement and inform you of known risks to uninterrupted service. We also support your exit strategy, in particular with all the information you need for it.

If the transition period is technically not feasible, we tell you with reasons within 14 working days of receiving the switching request and name a different transition period of no more than seven months; our services continue until it ends. You may extend the transition period once, by a period you consider appropriate.

Throughout the switch and the retrieval period we maintain a high level of security, in particular when the data is transferred.

When the transition period ends, or when the switch is completed earlier, a retrieval period of at least 30 calendar days begins in which you can still retrieve your exportable data (clause 16a.3).

The user agreement and the subscription end when the switch is completed and at the latest when the transition period ends; in case c, when the notice period ends. We tell you in text form when that is. After the retrieval period (in case c, after the user agreement has ended) we delete all exportable data and the agency's other data completely within 30 days. Clause 16.5 applies to statutory retention duties, legal claims and backups.

You do not have to order the export by a switching request: an owner can request it at any time during the user agreement (clause 16.4), as described below.

Formats and data structures

The export consists of files in JSON format (UTF-8) and the stored files as originals, together as a ZIP archive. Times are in ISO 8601 format in UTC. Identifiers (id, requestId, supplierId, userId and others) link the files to each other: requestId is the ID of a tender in tenders.json, supplierId that of a supplier in suppliers.json.

How to request the export

In the workspace: an owner requests the export on the page "Team" and downloads the finished file there.
Through the API: an organization key with an owner's rights requests the export, asks for its state and downloads the ZIP file once it is ready.

POST /api/agency/v1/exports
GET /api/agency/v1/exports
GET /api/agency/v1/exports/ID/download

The API is described in the OpenAPI description (OpenAPI 3.1, readable without a key) and in the developer documentation (in the workspace, sign-in required).

The export is free, needs no subscription and, during the user agreement, is available even after the subscription has ended.

Known restrictions

Only owners can request the export; through the API, only an organization key with an owner's rights can.
The export is built in the background. You see its state (waiting, being built, ready, failed, expired) and download the file once it is ready.
At most one export per organization is built at a time, and at most 5 exports can be requested in 24 hours.
The finished file is available for download for 7 days and is then deleted. After that, request a new export if you need one.
The export does not build an archive with more than 60,000 entries or more than 3.5 GiB, because the ZIP format we write cannot reliably represent larger archives; it fails in that case. Write to us at kontakt@mailingbid.com then, so that we provide the data another way.
Files that the database lists but that were no longer stored when the export ran are missing from the archive. They are listed in manifest.json under missingFiles; that is not an error.
The export contains webhook deliveries and incoming e-mails only as long as they are stored; e-mails only if they are assigned to your agency and we have handed them over to it.

Data structures

The archive contains these files. The file README.txt in the archive describes the layout in German and English.

manifest.json: Format version, time, number of entries per file and a list of files that were no longer stored at the time of the export (missingFiles), if there are any.
README.txt: Description of the layout in German and English.
organization.json: The agency: name, kind, country, language, billing e-mail address, chosen plan and billing interval, blocked yes or no.
members.json: Members: name, e-mail address, language, role, date of joining (userId is what authors, creators and confirmers refer to elsewhere).
team_invites.json: Invitations to the team: address, role, inviting member, expiry, acceptance, revocation. Without the invitation link.
suppliers.json: The agency's own supplier pool with all fields the agency keeps.
supplier_contacts.json: Contacts of the suppliers (supplierId): e-mail address, name, phone number as the agency keeps them.
tenders.json: Tenders with all fields: title, status, scope of services, offer deadline, payment terms, notes, on behalf of, own reference.
tender_tranches.json: Countries with quantities, dates and return addresses per tender (requestId).
tender_positions.json: The parts of the mailing per tender (requestId).
tender_files.json: Files of the tenders and offer PDFs (kind). The field file names the path of the file in the folder files/attachments/.
tender_step_confirmations.json: Confirmed working steps: step, confirming member, time.
tender_send_rounds.json: Sending rounds per tender.
invitations.json: Invitations: invited supplier (supplierId), released notes and files, inviting member, sending, first opening, decline with reason, withdrawal.
invitation_mails.json: Notes on which e-mail was sent when (invitation, reminder, result, notices to the team), with invitation and contact where known.
offers.json: Offers with all fields: provider, scope, price lines, totals, postage, currency, dates, terms, variant, origin (source), status (status).
decisions.json: Awards: chosen offers (selectedOfferIds), awarding member, time, internal comment.
comments.json: Team comments on tenders: text, author, reference to a part, times.
comment_reads.json: Read position per member and tender.
api_keys.json: Organization keys: name, first characters, creating member, times. Never the key itself.
webhook_endpoints.json: Webhook addresses with all fields. Without the signing secret.
webhook_deliveries.json: Deliveries and their log as far as stored.
subscription.json: The subscription: plan, billing interval, status, trial, billing period, cancellation, identifiers at the payment provider. Invoices are in the payment provider's customer portal.
inbound_messages.json: Incoming e-mails that our team checked and handed over to the agency as an offer, a decline or a forward: sender, subject, text, time of receipt, result of the sender check (senderCheck), draft of the automatic reading (extractionDraft), note on how it was handled (status, handledAt).
inbound_attachments.json: Attachments of these e-mails (inboundMessageId). The field file names the path in the folder files/inbound_attachments/.
files/attachments/: Files of the tenders and offer PDFs as originals, named by ID and file name.
files/inbound_attachments/: Attachments of the incoming e-mails as originals, named by ID and file name.

The version of the format is in manifest.json.

What is not exported

Only the following data cannot be exported (clause 16a.5), because handing it over would endanger the security of the platform, of the agency or of third parties, because it serves the internal operation of our service, or because it belongs to third parties or to us rather than to the agency:

Hashes, checksums and secrets, and the values secrets are derived from, in particular for access links of invitations and tenders, reply addresses, team invitation links, organization keys and signing secrets of webhooks.
The members' other account, session and login data, because an account can also be used outside the agency, and the accounts of the contacts in the supplier portal with their login data, because such an account applies to all supplier lists in which the person appears.
Counters against abuse, logs of background work, error logs, the log of the payment provider's notifications and our internal notes on reconciling the subscription with it.
Incoming e-mails not assigned to the agency, because they are not attributable to it; e-mails we have not yet checked or have not handed over but discarded, because under clause 6.2 the agency only receives them after our check; and the information which person in our office handled an incoming e-mail.

There are no digital assets within the meaning of Art 25(2)(e) of the Data Act beyond this.

Charges

We charge nothing for the switch, the export and the assistance with the switch (clause 16a.6). The API is available free of charge for the export and the switch, also without a subscription and also for receiving providers that you designate for this (clause 16a.7).

The fee for a running subscription remains due until it ends. If the subscription ends before the end of the billing period because of the switch, fees already paid are not refunded pro rata (clause 11.5).

Jurisdiction of the infrastructure used

The ICT infrastructure that Mailingbid for agencies runs on is located in these countries and is subject to their law (service providers and places of processing as in Annex 2 of the data processing agreement):

Hetzner Online GmbH, Germany: server in the data centre in Nuremberg (Germany) and encrypted backup copies in the data centre in Helsinki (Finland). All data of your agency is stored here.
Sendinblue SAS (Brevo), Paris, France: sending the platform's e-mails, in data centres in France and Belgium. According to Brevo, some of its sub-processors are located outside the EEA, in particular in the USA and India.
Mistral AI SAS, Paris, France: reading offers that suppliers send by e-mail, through an endpoint in the EU; according to Mistral, in data centres in the EU and in EFTA states.
Proton AG, Switzerland: receiving and storing the e-mails sent to our addresses (mailboxes); data of your agency only occasionally, for example in a message to us.

Which of these providers use sites in third countries themselves, and on what basis, is set out in Annex 2 of the data processing agreement.

Protection against access by third-country authorities

If an authority of a third country demands access to your agency's data, we tell you before complying with the demand, unless a law-enforcement purpose prevents it (clause 21.2, Art 32(5) Data Act).

The platform runs on a server in Nuremberg and its backup copies are in Helsinki. Both locations are in the EU and belong to the same host, Hetzner Online GmbH, which is based in Germany.

The external backup copies are encrypted and are transferred over an encrypted connection (SFTP). All connections to the platform use HTTPS (TLS), as do the platform's connections to the services for sending e-mail, retrieving attachments and reading offers.

The database, the files and the backups on the server itself are not separately encrypted. They sit in the server's file system, which can only be reached through the access routes described in Annex 1 of the data processing agreement.

The terms in full

The Terms of Use and the data processing agreement are binding. The clauses referred to: