Privacy Policy
The German version is legally binding.
Controller
Christoph Salat, Sieveringer Straße 94/10, 1190 Wien, Austria
Email: kontakt@salat.tech
Questions about the platform: kontakt@mailingbid.com
Visiting the website
When you visit the website, your browser technically transmits data to our server, in particular IP address, date and time, the address requested, browser type and language setting. We process this data to deliver the website and protect it against misuse: when submitting a request, requesting a login link, and checking an email address, we count the attempts per IP address and per email address; likewise we count failed attempts to open or redeem a login link or an invitation link (per IP address), invitations to a team (per organisation, invited address and IP address), accepting an invitation and cancelling a subscription through a link (per IP address), and visits to invitation pages and to the cancellation page whose link is not valid (per IP address), quotes submitted (per IP address and invitation) and files downloaded by suppliers (per invitation), failed logins at the interface (per IP address), calls to the interface (per key), received replies (per invitation) and changes in the workspace (per organisation, member, tender, supplier or webhook address, in each case by our internal number). These counters exist only in the server's working memory, lose effect after at most 24 hours, and are discarded at the latest when the application restarts. In the event of errors, the application and the upstream web server log the time, the error and the address requested; this may also include the IP address and details from the failed request. We retain these logs for as long as they are needed to fix the error. We make backups of the platform's database and files: about 15 daily snapshots are kept on the server, and 7 daily, 4 weekly and 6 monthly snapshots, encrypted, in storage at Hetzner in Helsinki; in addition, the Hetzner Cloud backup function is enabled for the server. Deleted data remains in these copies until they expire and are overwritten, that is for up to about six months. The legal basis is our legitimate interest in a secure and stable operation of the website (Art 6(1)(f) GDPR).
If an unexpected error occurs on the server (an error in the application, or a response with status code 500 or higher, but not the answer to a wrong input such as 400 or 404) or a background job fails, we report it to an error monitor (Glitchtip) that we run ourselves on the same Hetzner server in Nuremberg. There is no further recipient and no transfer to a third country; the sender of the reports is the server itself. A report contains the error message, the technical trace (files and lines of the program), the time, the kind and path of the requested address without anything after the question mark and, for a background job, its kind, number and attempt. Cookies, headers and content of the request, form input, account identifiers and your IP address are not part of it. Before sending, we remove links that carry a secret, e-mail addresses and the values of database queries from the texts. Because error messages can be freely worded, we cannot rule out that in rare cases a piece of text from the failed request appears in one. We process the reports to detect and fix errors and to keep operations secure (Art 6(1)(f) GDPR), and we delete them automatically after 90 days.
Web analytics (Umami)
To understand how the website is used, we use the open-source software Umami, which we run ourselves on our server at Hetzner in Nuremberg (accessed via stats.mailingbid.com); apart from Hetzner as our host, nobody receives this data. Umami sets no cookies and stores nothing on your device; the script merely checks whether you have switched Umami off in your browser yourself (an "umami.disabled" entry in the browser's local storage). We record the pages visited, the referring page (referrer), browser, operating system, device type, screen size and language, the country, region and city that Umami derives from the IP address, and, without any content, the fact that a request was submitted, details were saved or an offer was awarded, as well as whether the paper weight calculator was used or a request was started from it. For the QR code generator, we record that a code was generated, an SVG or PNG file was downloaded, or a print request was started, without recording the destination URL or any other input. Before anything is sent, we shorten the addresses: the number of a request is replaced by a placeholder, access and login links are recorded without their key, and the internal admin area is not recorded at all; of an address's parameters only campaign details (utm_source, utm_medium, utm_campaign, utm_content, utm_term) are kept, and of an external referring page only its domain. The IP address is not stored but only processed briefly: Umami combines it with your browser's identifier (user agent) and a secret value that changes monthly into a session identifier, plus an identifier that changes hourly to tell individual visits apart. Visits therefore cannot be linked beyond the calendar month concerned, and we cannot identify individual visitors. We keep the statistics in this form indefinitely. The legal basis is our legitimate interest (Art 6(1)(f) GDPR) in statistically evaluating the use of the website in order to improve content and forms and to see through which channels visitors find us.
Submitting a request
When you submit a request, we process your contact details (name, email address, optionally organisation and phone number), the details of your mailing (title, parts of the mailing with format and execution, countries with code, quantity, date, artwork variants, postal product and return address (the same country can occur more than once), scope of services, offer deadline, notes), whether you request as an organisation or as an agency and, if so, on whose behalf, and any preferred payment terms and the files you upload. The purpose is to obtain offers for your request and provide them to you. The legal basis is the performance of pre-contractual measures at your request (Art 6(1)(b) GDPR); if you submit the request on behalf of an organisation, we base the processing of your contact details on our legitimate interest in handling requests from organisations (Art 6(1)(f) GDPR). Providing your name and email address is required for a request; without them we cannot obtain offers and deliver them to you.
We store requests, including files, offers and your selection, for as long as your request is being processed or your account exists, and beyond that only insofar as statutory retention obligations apply or we need them to assert or defend legal claims (Art 6(1)(f) GDPR).
Sourcing and awarding offers
For the calculation, we pass on the details of your request that are necessary to selected printers and lettershops: parts of the mailing, countries with quantities, dates and postal products, artwork variants, scope of services, offer deadline, payment terms, notes on format and execution, and files insofar as they are needed for the calculation. Providers see these details in our supplier portal, via a personal link or with their account; we only pass on your notes on the request after reviewing them. These providers do not receive your name, your contact details, the organisation on whose behalf you request, the codes you give to individual rows of the country list or return addresses; however, if files show your organisation, it will be recognisable to them. If you bindingly select offers, we store your selection together with any comment and pass it on to the chosen providers; for this we pass your name, organisation, contact details and, where applicable, the commissioning organisation, the codes you give to individual rows of the country list and return addresses to the chosen providers so the order can be placed and fulfilled. This happens automatically by email to the provider's contact persons (each person receives an email of their own); Brevo carries out the sending as our processor. If a provider has no contact person we can reach, our office passes the details on by hand. We record which contact person we have notified for which offer so that nobody is notified twice or missed. The legal basis is Art 6(1)(b) GDPR. The retention period is the same as for requests. For contact persons at printers and lettershops, we process for the supplier portal their email address, optionally their name, the times of account activation and last login, login links (stored only as a hash, valid for 30 minutes, single use) and the session cookie described below; the legal basis is Art 6(1)(b) and (f) GDPR (obtaining and handling orders). We keep this data for as long as the person is registered as the provider's contact.
Marketplace providers: agreement to the terms and billing details
Before a provider submits a quote to an invitation from the marketplace, a signed-in contact person agrees to the marketplace terms on its behalf, confirms that the provider is a business and that the contact may represent it, and gives the provider's billing details: company name, address, VAT ID and an email address for invoices. We store these details with the provider, together with the version of the terms, the time of the agreement and the contact person who agreed. The agreement covers the provider and all its contact persons. Our office sees these details in the supplier administration; we do not show them to clients or other providers, and they are never collected for invitations from agencies. We process them to invoice the success fee and to prove that the contract was concluded; the legal basis is Art 6(1)(b) and (c) GDPR.
We keep these details for as long as the provider is listed in the marketplace and delete them with the provider, unless a statutory retention duty applies. For invoices and the related records it is seven years (section 132 of the Austrian Federal Fiscal Code, BAO). If the contact person's account is deleted, the agreement stays on record without a reference to the person.
Marketplace: invoicing the success fee
After an award we invoice the chosen provider for the success fee on the basis of the accepted offer as it is stored on the platform, made out to its billing details and sent to its email address for invoices. If the net order value changes by more than 10 %, or if an order for a request comes about outside the platform, the provider tells us by email together with the net order value; on request it proves the final net order value with the order confirmation and the invoice to the client, blacking out any recipient data. For this we process the order value, these messages and documents including the details about the client they contain, and our invoices and credit notes, in order to calculate, invoice and correct the fee. Towards the provider and its contact persons the legal basis is Art 6(1)(b) and (c) GDPR; for the details about the client in these documents it is our legitimate interest in invoicing the fee correctly (Art 6(1)(f) GDPR).
We may ask the client whether an order came about and at what value. For this we use the contact details from the request or the account and process the answer; the legal basis is our legitimate interest in invoicing the fee correctly and checking what providers tell us (Art 6(1)(f) GDPR). Answering is voluntary.
These emails, that is messages and evidence from providers, our questions, clients’ answers, invoices and credit notes, go through our mailbox at Proton AG as our processor (see below under contact by email); there are no recipients other than our office and the provider receiving its own invoice. We keep invoices and the related records, including the messages, evidence and answers on the order value, for seven years (section 132 of the Austrian Federal Fiscal Code, BAO).
Marketplace: reports of illegal content
If you report content on the marketplace that you consider illegal, such as a request, a file or an offer (Art 16 of Regulation (EU) 2022/2065), by email to our contact address (see above), we process your name, your email address and the content of your report with any attachments, in order to examine the report, confirm receipt and tell you our decision together with the possible means of redress. The legal basis is Art 6(1)(c) GDPR in conjunction with Art 16 of Regulation (EU) 2022/2065. For reports of offences under Arts 3 to 7 of Directive 2011/93/EU you do not have to give a name or an email address, but then we cannot reply to you.
Emails to this address are received and stored by Proton AG as our processor (see below under contact by email). If we then do not pass on a request, notes or files, do not release an offer, withdraw an invitation or block a user, we send the client or provider concerned our reasons by email (Art 17 of Regulation (EU) 2022/2065): the measure, the facts we rely on, whether a report prompted it, and the possible means of redress; we do not give them your name or your email address.
We keep your report, our replies, the statement of reasons sent to the person concerned and our correspondence on the matter in the mailbox for as long as the matter is open and for no more than three years after that, because we need them to establish or defend legal claims (Art 6(1)(f) GDPR).
Account and login
We create an account once you bindingly select an offer for the first time or create one yourself, for example for API access; even then it only comes into being when you open the link in our email. For this we process your email address, your name, optionally organisation and phone number, your language setting, and the times your account was created, your email address was confirmed, and you confirmed having read this privacy policy. You agree to the terms of the marketplace at the first selection of an offer, at the next selection while your account has not yet agreed to the version in force, and when creating an account for API access; we then also store with the account your confirmation that you act for a business or an organisation, the version of the terms and the time of your consent; the legal basis is Art 6(1)(b) GDPR. Login is passwordless, via links we send you by email; a link is valid for 30 minutes and can only be used once, and only a hash of it is stored. Together with the link we store the email address and, if you use it to confirm a selection, the selection together with any comment and, where applicable, your details for the new account, and, if you have agreed to the terms of the marketplace, that consent (the version and the confirmation that you act for a business); we retain this data for as long as the associated request exists or your account data exists. The legal basis is Art 6(1)(b) GDPR. If an account takes over a request whose contact email address is a different one, we inform that contact address of the account's name and email address; the legal basis is our legitimate interest in making a takeover via a forwarded access link recognisable to the original contact person (Art 6(1)(f) GDPR). If you create API keys, we store for each key its name, its first characters, a hash of the key and the times it was created, last used and, if applicable, revoked; requests made via the API are processed like requests from the form. We store account data for as long as your account exists; after that, the same applies as for requests. Without an account, no offer can be bindingly selected.
Emails
We send you the emails needed for your request and your account: the confirmation of receipt with your access link, the notice that offers are available, login links, and confirmations and notices about your selection. We also send your selection to the selected providers, as described below. In doing so, we process your email address, your name and the content of the email. The legal basis is Art 6(1)(b) GDPR. Sending is carried out by Brevo as our processor; Brevo retains delivery logs and copies of the emails on our behalf for as long as they are needed to prove delivery.
Contact by email
If you write to us at kontakt@mailingbid.com, we process your email address, your name if given, and the content of your message including attachments in order to deal with your enquiry. The legal basis is Art 6(1)(b) GDPR where it concerns a request, an offer or a contract, and otherwise our legitimate interest in answering messages (Art 6(1)(f) GDPR). Emails to this address are received and stored by Proton AG (Route de la Galaise 32, 1228 Plan-les-Ouates, Switzerland) as our processor. We keep the messages until your enquiry has been dealt with, and beyond that only insofar as statutory retention obligations apply or we need them to establish, exercise or defend legal claims.
Writing to companies by post
We write by post to companies in Germany and Austria that could be agencies, printers or lettershops, to tell them about Mailingbid. For this we process the company name, the business postal address, the name and role of a contact person (for example managing director, owner or head of production) where the company states them publicly, the company's website, where we found the company, the date we collected the details, whether and when we sent a letter, and any replies and objections. We do not process private addresses or special categories of data; we do not build profiles, make automated decisions or buy data from address brokers. We approach companies by email or telephone only if they have agreed to it beforehand.
The details come from the company's own website (imprint, team and contact pages) and from public directories: member and service-provider directories of industry associations, the Austrian Post's list of certified service partners, and business directories. The letter names the source (the imprint of your website) and the month we collected the details.
The legal basis is our legitimate interest in informing companies about our service by post (Art 6(1)(f) GDPR, recital 47). We print and post the letters ourselves; no printer or lettershop receives the addresses.
We keep the list in Notion (Notion Labs, Inc., USA) as a processor and as a spreadsheet on our own computer. It is not in the platform's database and is not visible to users of the platform. For the transfer to the USA, see "Recipients".
We keep the details until an objection and otherwise for as long as we want to write to your company. If a company does not reply, we delete its entry 24 months after the last letter. After an objection we no longer write to your company and keep only what is needed to honour the objection: company, address and date of the objection.
Your other rights and the right to lodge a complaint are set out under "Your rights".
Objection to letters: You may object at any time, without giving reasons, to the processing of your data for these letters (Art 21(2) and (3) GDPR), by email to kontakt@mailingbid.com or by post to the address under "Controller". We will then no longer write to your company.
Agency platform: account, organisation and team
When an agency registers, we process the agency's name, your name, your email address, the agency's country, the language chosen, the plan chosen including the payment interval, your confirmation that you are registering a business, the version of the terms of service you agree to and, if you give it, your VAT ID (UID), company register (Firmenbuch) or ZVR number. As with any account, these details travel in the login link (only a hash of the link is stored; it is valid for 30 minutes and can be used once); opening the link is what creates the account and the organisation. For the organisation we store its name, its country, the language for emails sent in its name, until a subscription exists the plan chosen at registration including the payment interval (as the preselection on the billing page), on request an email address for invoices, and the identifier of its customer record at Stripe (see below); for each member we store the role (owner or member) and the date they joined. All members of an organisation can see the names, email addresses and roles of the other members. As proof of the contract we also store with the organisation the confirmation that you act for a business and may represent it, the version of the terms of service and data processing agreement that was agreed to, the time of the agreement (opening the login link), the person who agreed and, if given, the VAT ID (UID), company register (Firmenbuch) or ZVR number, for as long as the organisation exists; the legal basis for this is Art 6(1)(b) and (f) GDPR (our interest in being able to prove the contract). For the other details the legal basis is Art 6(1)(b) GDPR.
Owners of an organisation can invite colleagues to the team by email. For this we store the invited email address, the owner who invited, the times of the invitation, its expiry (after 7 days), acceptance and revocation, and only a hash of the invitation link, before the invited person has done anything and even if they have no account yet; an email naming the agency and the person who invited goes to the address. The invitation page shows the address only partly masked (first letter and domain). Whoever accepts the invitation gets a login link sent to the invited address; opening it is what makes them a member. Until they join, the legal basis for the invited person's data is our legitimate interest in enabling agencies to work together as a team (Art 6(1)(f) GDPR), afterwards Art 6(1)(b) GDPR. When a member is removed or leaves the team, their membership ends and the organisation keys they created are revoked; their account remains, and the tenders they created stay with the organisation.
We store the data of the organisation, its members and its invitations, including expired and revoked ones, for as long as the organisation exists. After the user agreement ends, the owners can still export the data for at least 30 days; after that we delete the organisation with this data within 30 days. If the agency has requested deletion, we delete within 30 days after the user agreement ends. This applies unless a statutory retention obligation applies and we do not need it to establish or defend legal claims (Art 6(1)(f) GDPR); before that, we delete on your request. The accounts of the individual people are not affected. Together with the organisation we also delete the login links that are waiting for an invitation of this organisation. Other login links, expired and used ones too, stay stored with the email address, the times and, for a registration, the details that travelled with the link, until we delete them on your request. When we notify the owners of something the contract promises them (a new sub-processor, a change to the terms or the prices), we keep a record of which notice went to which email address (owners and, for prices, the billing address), with the time and the result of sending. This lets us prove that we kept the notice periods (Art 6(1)(b) and (f) GDPR), and we keep the record for as long as the organisation exists.
Agency platform: an agency's supplier list
Each agency keeps its own list of lettershops and printers. It enters them one by one or by CSV file: the supplier's name, type, country, language, its own number, internal notes, whether the supplier is ISO 27001 certified, and the contacts at the supplier (email address, optionally name and phone number, at most ten per supplier). We read a CSV file only for the preview and the import and do not store it; what is stored is what the agency adopts after the preview. The agency alone decides which persons it enters; it is responsible for these contact details (in particular for the legal basis and for informing the persons concerned). We process them on its behalf, to send tenders to these contacts and to give them access to the supplier portal.
The list is not visible to any other agency, is not used for the marketplace, and does not appear in our office's supplier administration; as the operator we can technically access the stored data where operation or troubleshooting requires it. The same person can appear in several lists (the marketplace's and those of several agencies). They then have one shared account for the supplier portal, where they log in by a link sent to their email address; each list keeps the name and phone number for itself, and no list learns about another. We are ourselves responsible for this account and the login (Art 6(1)(b) and (f) GDPR); for contacts of the marketplace, our administration shows when the account was activated and when the person last logged in, even if the login was for an agency's tender; what the person does there, our administration does not show.
We store a contact for as long as the agency keeps it in its list. If the agency removes the contact, we delete the link; if it was the person's last list, we also delete their account including login links. A supplier that has already been invited can only be deactivated by the agency; its contacts then stay stored until the agency removes them or we delete the organisation after the user agreement has ended.
If your details are in an agency's supplier list, or you have received an invitation from an agency or a reply address from us as a supplier, you can contact kontakt@salat.tech with any requests about your rights. We pass them on to the agency insofar as it is responsible.
Agency platform: tenders, invitations and quotes
An agency creates tenders: title, parts and countries of the mailing (quantities, dates, formats, specification), scope of services, offer deadline, payment term, notes, files and, optionally, its own reference and the party it tenders for. We also store the name and email address of the member who created the tender and the name of the organisation. When the agency sends the tender, each contact of the chosen suppliers receives an email of their own (sent via Brevo as our processor; the sender address is our platform's, the text names the agency). It states the name and email address of the inviting member for questions, the offer deadline and a personal link to the supplier portal, may contain a message from the member, and carries the tender as a PDF. Replies to this email go to a reply address assigned to this invitation alone, which Brevo receives for us (see below); if it is not set up, they go to the inviting member. If the agency sends an invitation again or returns a quote for correction, a further email goes to the supplier's contacts each time. Two working days before the offer deadline we remind by email the contacts who have not yet submitted a quote; once the deadline has passed, we tell the inviting members how many quotes have come in.
A tender is worked out in steps (parts, countries, services, files, summary), and any member of the organisation can confirm a step, including by saving it. For each step we store which member confirmed it, that member's name as it was at the time (it stays even if the account is later removed), the time, and a fingerprint (hash) of the content, which shows whether the step has changed since. Only the members of the organisation see this (through the API too), no supplier, email, PDF or webhook does; it is kept for as long as the tender, and the confirmation of a removed part goes with the part.
Unlike requests through the marketplace, the invited suppliers learn here who is asking: the email, the PDF and the supplier portal state the agency's name and the name and email address of the inviting member. They do not see the title, the party the tender is for, the agency's own reference, the codes of individual rows of the country list or return addresses; notes and files of the tender only if the agency releases them. Suppliers submit their quote (prices, terms, PDF files, comment) or their decline in the portal. A submitted quote goes immediately and directly to the agency, without review by us; the inviting members receive an email about it. Every email to a supplier's contact persons (invitation, reminder, renewed link, returned and recorded quote, result) names the agency as the controller of their contact details (Art 14 GDPR) and, if the agency has saved a link to its own privacy notice in the workspace settings, points to that notice; we store the link with the organisation. The reference to this privacy policy stays.
When a member awards the tender, we store the quotes chosen, the member who awarded it, the time and an optional internal note. Each invited supplier whose invitation was not withdrawn then receives, for each contact, an email with the result: chosen (stating what for, and noting that the agency will be in touch), not chosen or, if the supplier submitted no quote, that the request is closed. The email names the number of the request and nothing about other suppliers, quotes or prices; replies to it go to the agency's contact person.
We handle the following on behalf of the agency, which is responsible for them (Art 28 GDPR): the supplier list including contact details, the content and files of tenders, the invitations, reminders and result notices, received quotes and awards, data read or written through the agency's interface and webhooks (to the same extent as entries made in the workspace), and details about third parties in comments. We process the members' data under Art 6(1)(b) GDPR. We keep tenders, invitations and quotes for as long as the organisation exists. After the user agreement ends, the owners can still export the data for at least 30 days; after that we delete the organisation with its tenders and their files, invitations, quotes, comments, supplier lists, received emails with their attachments, webhooks and keys within 30 days; if the agency has requested deletion, within 30 days after the user agreement ends. This applies unless a statutory retention obligation applies. An agency can delete a tender that was never sent itself; otherwise we delete on request unless a statutory retention obligation applies and we do not need the data to establish or defend legal claims. Deleted data remains in backups until they expire and are overwritten, for up to about six months (see the section on backups above).
Agency platform: comments in the team
The members of an organisation can write comments to one another on a tender. We store the text, the author's name as it was when writing, the times of writing, of a change (by the author only, within the first 15 minutes) and of deletion, on request the reference to a part of the mailing (number and description of the part at the time of writing) and, for each member and tender, the time up to which the member has read the thread. The thread is loaded as soon as a member opens the tender's page and, while the window is visible, refreshed every 20 seconds; we set the read mark only once the comments section has been in view for a moment, not on loading. It feeds the counter of unread comments in the interface, and there is no email about it. If a member writes through an API key, the comment appears under the name of whoever created the key. The legal basis is Art 6(1)(b) GDPR. What the comments say is up to the members; if they contain data of third parties, such as contacts at suppliers, the agency is responsible for it and we process it on its behalf.
A comment is seen only by the current members of the organisation the tender belongs to. No supplier, email, PDF, webhook or page of our administration shows it; as the operator we can technically access the stored data where operation or troubleshooting requires it. Whoever is removed or leaves the team can no longer read or write anything; the comments that member wrote remain readable for the team under the stored name.
Comments are stored for as long as the tender they belong to and are deleted with it (an agency can delete a tender that was never sent). When the author or an owner deletes a comment, its text is emptied; author, times and reference remain in the thread as a placeholder. The read mark of a removed member remains until the tender or their account is deleted. There is no further automatic deletion.
Agency platform: subscription and payment (Stripe)
An agency's subscription is handled through Stripe. To pay, and to manage your payment method, invoices and billing details, we send you to pages operated by Stripe (Stripe Checkout and the customer portal). You cancel on our subscription page or through the link in our emails, not at Stripe. The checkout names the terms of service for agencies with their address and, where we have switched this on, can ask for your consent to them; Stripe takes the consent and tells us whether it was given. We load no scripts from Stripe on our own pages, and payment details never reach our server: Stripe itself collects the payment method (card or SEPA direct debit), the billing address and, where applicable, the tax number. We create a customer at Stripe and transmit for this the organisation's name, the billing email address (if none is stored, the email address of the owner who takes out the subscription), the organisation's country and language, our internal number of the organisation, and the plan, payment interval and price. The legal basis is Art 6(1)(b) GDPR.
We store the identifiers of the Stripe customer and the subscription, plan, payment interval, status, the end of the trial, the start and end of the current period, a scheduled change of plan (plan, payment interval and when it takes effect), the time a trial was extended, the time of the first tender sent (whether a charge is made depends on it), the times and notes of a cancellation and of the end of the subscription, a note with a time if the state at Stripe could not be confirmed, and a log of the notifications Stripe sends us (identifier, type, time and, where applicable, an error text). From the notifications we take identifiers and ask Stripe for the current state; for a paid invoice we also read the invoice identifier, amount, currency and the time the invoice was created, and for a disputed payment the amount and reason, so that our office can be informed. We do not store invoices themselves; we ask Stripe for them when we need them, for instance to check, before an email about a subscription that ended unused, whether anything was paid, or when our office looks at an organisation's latest invoices in its internal overview (date, identifier, number, status, amount, tax, currency and the links to the invoice at Stripe); none of this is stored with us then either. Three exceptions, each in a report to our office: if an invoice for an amount is paid for an organisation that has never sent a tender, or an invoice for an amount is paid that was created only after a cancellation, we record the name and number of the organisation, the identifiers of customer, subscription, invoice and notification, the status of the subscription, and the amount and currency so that the amount can be refunded; if an invoice is still open when Stripe ends the subscription, we record the same details without the identifier of a notification, so that our office can decide whether to follow it up. Once one of these reports has been sent, we delete the entry stored for it 90 days later; the email to our office stays in the office's mailbox. Where the consent to the terms of service was asked for in the checkout, we store at the organisation the time Stripe told us about it and the version of the terms that applied. Card and account details, billing address and tax number are held by Stripe alone. We keep the subscription data for as long as the organisation exists; the log of notifications contains no details about persons and is not deleted automatically. Our office can set a maximum number of tenders for an organisation in the current period that differs from its plan; it applies at most until the end of that period. For this we store the maximum, the period, plan and payment interval it applies to, a note giving the reason, and which office account set or lifted it and when. These entries are kept as a history for as long as the organisation exists and are deleted with it; if an account that set or lifted an entry is deleted, we remove only the reference to that account. The legal basis is Art 6(1)(b) GDPR, and for the history also our legitimate interest in keeping a traceable record of exceptions (Art 6(1)(f) GDPR).
If automatic tax calculation is switched on (Stripe Tax), Stripe calculates the VAT from the billing address and the tax number (VAT ID) that you enter on Stripe's page, and shows it on the invoice. We send Stripe nothing extra for this, because Stripe's page asks for the billing address and the tax number in any case, and we store neither the address entered nor the tax number. The sentence we show on Stripe's page beside the button is a fixed text about charging that also names the terms of service with their address, and contains no personal data. The legal basis is Art 6(1)(b) GDPR and, for showing the tax on the invoice, also Art 6(1)(c) GDPR; Stripe is our processor for this too (see below).
For this processing Stripe is our processor; for its own purposes (such as fraud prevention and legal obligations) Stripe processes data as an independent controller, see Stripe's privacy policy (stripe.com/at/privacy). According to Stripe, the contracting entity for customers in the EEA is Stripe Payments Europe, Limited (Ireland). To provide the service, data is also transferred to Stripe, LLC in the USA; the basis is the transfer instruments agreed in the data processing agreement with Stripe (EU-US Data Privacy Framework or standard contractual clauses).
About the subscription we send the owners of the organisation and, if a different billing email address is stored, that address too, an email of their own each (sent via Brevo as our processor, in the language of the account or the organisation): at the start of the trial, with plan, price and the end of the trial; after the first tender is sent, with the day and amount of the first charge; as a reminder before the end of the trial, as a rule 7 days and 1 day before (also when nothing will be charged because no tender was sent); when an unused trial is extended once; when a subscription ends without a charge; and as a confirmation when the subscription has been cancelled. We send them only while the state of the subscription at Stripe is confirmed. The legal basis is Art 6(1)(b) GDPR; for a billing email address that belongs to no owner, our legitimate interest and that of the agency in sending notices about charges and cancellation there (Art 6(1)(f) GDPR).
The notice of the first charge and the reminders contain a link for cancelling without logging in. The link is a value we sign from the number of the organisation, the identifier of the subscription and an expiry time, and it is stored nowhere; it is valid until three days after the end of the trial it was issued for. Whoever opens the link first sees what a cancellation would do: the name of the organisation, the plan, the dates (end of the subscription, charge) and the amount; if the subscription has already ended because a payment could not be collected, it says so and gives the amount of any invoices still open. Opening it never cancels; only a button on the page does. Whoever has the email or the link, also after it was forwarded, can see these details and cancel the subscription. When it is opened we only read the state at Stripe and change nothing; only when the button is pressed do we compare it with Stripe. What is stored is the cancellation with its time, not who triggered it; the confirmation goes to the owners and the billing email address. The page is not recorded in the statistics (Umami).
If problems arise in billing, such as a cancellation that did not reach Stripe, a subscription whose state cannot be confirmed, a plan, a date or an end date at Stripe that nobody on our side asked for, a second subscription of the same organisation, a disputed payment, a charge after a cancellation, a charge without a tender sent or an invoice that was still open when Stripe ended the subscription, we send a report to the platform's office address (an address on our domain mailingbid.com that, like the contact address, is received by Proton AG). It gives the name and number of the organisation, the identifiers at Stripe and, depending on the case, status, plan, dates, invoice identifier, amount and currency, reason or error text, but no payment methods and no content of tenders. We also mark an invoice that was left open after the end of a subscription as uncollectible at Stripe: Stripe then stops trying to collect it; it stays visible and can still be paid. Most of these reports are also stored with these details in the log of our background jobs, so that they reach our office even if sending email fails at that moment; once such a report has been sent, we delete the entry 90 days later. Not stored there, only sent, are the reports about a state that a later check finds again: an unused subscription in its trial whose end is not scheduled at Stripe, a cancellation that did not reach Stripe, a state that cannot be confirmed, a price at Stripe that we do not know, a notification from Stripe that we could not process, and a subscription that belongs to another customer at Stripe, if that comes to light not through a notification from Stripe but in another check.
Agency platform: API keys and webhooks
Members of an organisation can create organisation keys, with which the agency's own software uses the platform's interface (API). For each key we store its name, its first characters, a hash of the key (the key itself is shown only once, when it is created), the member who created it, and the times of creation, last use (updated at most once a minute) and revocation. A key acts as this member: a tender, invitation, comment, confirmation of a step or award made through the interface carries that member's name and address as if they had triggered it in the workspace themselves. What is sent or retrieved through the interface we process like input in the workspace. If the member leaves the organisation or is removed, their keys for this organisation are revoked and stay invalid even if they rejoin later. The legal basis is Art 6(1)(b) GDPR. We keep the keys, revoked ones too, for as long as the organisation exists; there is no automatic deletion.
Owners of an organisation can enter webhook addresses (HTTPS) for the agency's own software. We store the address, an optional description, the subscribed events, the state, the member who created it, and a random value from which the signing secret is derived; we do not store the secret itself. When something changes on a tender (first sending, quote received, decline, deadline reached, award), or an owner requests a test event, we send signed JSON to these addresses. It contains only the identifier and type of the event, the time, our number of the organisation, the numbers of the tender, invitation, quote, supplier or award concerned, and the agency's own references for the tender and the supplier; no names, addresses, prices or texts of suppliers. Where the events go is for the agency alone to decide; it is responsible for the receiving systems, and we send on its behalf. The legal basis is Art 6(1)(b) GDPR.
For each delivery we record the content of the event, the state, the number of attempts, the times, the status code of the last answer and, on failure, its class (such as a timeout), and also, if the recipient's answer was not a success, an excerpt of the answer (at most 200 characters, text only); the members of the organisation see this in the workspace. We store nothing else of the recipient's answer. On failure a delivery is tried at most eight times, spread over about 24 hours; after eight failed attempts in a row at an address we switch it off and send the owners an email with the name of the organisation, the host name of the address (without path), the description and the number of failed attempts. We delete deliveries with their log automatically 30 days after the event, whatever their state; the address itself stays stored until an owner deletes it or the organisation is deleted.
Agency platform: suppliers' replies by email
Each invitation has a reply address of its own on our reply domain. When a supplier replies to the invitation, Brevo receives the email as our processor and passes it to our server through a protected interface. We store the sender's address and name, the address the email was sent to (our reply address there, and in the content of the email, without its secret part), the subject and the text of the email (if it has only an HTML part, the text made from it; we do not store the HTML itself), technical details (message identifier, date, spam score and, where the delivery contains them, the results of the receiving mail server's sender checks under SPF, DKIM and DMARC) and the attachments (PDF, images, text files); we download the attachments from Brevo and keep them apart from the files of the tender. From the spam score and the sender checks we derive whether the sender counts as verified, not verified or suspicious. We also store emails that cannot be matched to any invitation, because anyone can write to these addresses, but without their attachments: of those we record only the name, the stated file type and the stated size, and the identifier with which the file can be fetched from Brevo. Only when we match such an email to an invitation by hand do we download its attachments from Brevo. Nor do we download the attachments if the invitation has been withdrawn, or if more emails with attachments arrive in a day than our daily allowance provides for; in those cases too we record only these details. If more emails arrive than we store (50 in 24 hours and 100 unhandled per invitation, 500 in 24 hours per organisation, 100 in 24 hours without an invitation; for emails from a contact on file whose sender the receiving mail server has verified we keep further room free: up to 100 in 24 hours and 150 unhandled per invitation; the limit per organisation does not apply to these emails), we do not store the further ones and only record how many there were per invitation and day and how many of them came from such a contact.
To begin with, only we see a received email (people in the office with access to the administration); the agency does not see it before we have reviewed it. We receive a notice that names only the number of the tender and the name of the supplier entry, nothing from the email; about emails that were not stored we receive at most one notice per invitation and day, which also names their number. Only after our review does the content of a reply reach the agency, as described in the next paragraph. The legal basis is our legitimate interest in receiving suppliers' replies, reviewing them, making them available to the agency and limiting misuse in the process (Art 6(1)(f) GDPR).
In the review we see the sender, recipients, subject, text and attachments of the email and the result of the sender checks next to the draft from the reading, and decide what the email is. We record a quote ourselves in the form of the supplier portal (prices, terms, chosen PDF attachments, which we attach to the quote as a copy); the agency sees it as a quote received by email, the inviting members receive an email about it, and each stored contact of the supplier receives an email asking them to check the entry, with a link to the portal. We note a decline with its reason; the agency receives an email about it. Questions and everything else we forward by email to the members of the agency who also receive the other emails on this tender (the inviting member, otherwise the owners): it contains the subject and text of the email as a quotation and the attachments we chose. This email names a contact of the supplier as the sender only if the sender's address is stored as a contact and the receiving mail server has verified it. Otherwise it says only that a message arrived at the reply address whose sender is not verified, and shows the address as a quoted line without a link, because it can be forged. An email we could not match to any invitation we match by hand to an invitation where needed; an email of no relevance we dismiss with a reason (spam, duplicate, other) and a short note, without anyone being notified. Which person in the office handled an email, and when, we keep with the email.
We delete emails that could not be matched to an invitation, with their attachments, 30 days after they arrive, and emails we have dismissed, with reason and note, 90 days after dismissal. An email that belongs to a tender, including one we have matched by hand, recorded as a quote or forwarded, stays with that tender together with its attachments for as long as the organisation exists, and is deleted with it when we delete the organisation after the user agreement has ended. Brevo also keeps event logs of received emails according to its own periods.
Agency platform: reading replies with AI (Mistral)
To capture prices from replies we use, where we have switched the function on, the AI service of Mistral AI (Mistral AI SAS, Paris, France) as our processor. Only emails matched to an invitation to an agency's tender go there, and only while the invitation has not been withdrawn, the supplier has not been deactivated, the tender is neither closed nor awarded and the agency has not been switched off on our side. If the supplier declined earlier, we still read its email, because it can still submit a quote. An email about a marketplace request never goes there, and neither does an email that cannot be matched, not even if we match it by hand later, unless we then expressly trigger the reading. What is sent is the subject and text of the email including signature and quoted earlier messages (and so any names, phone numbers and email addresses in them), PDF files and images for text recognition, and text attachments, together with the file names of these attachments. From the tender we send only its structure (for each country quantity and posting date, for each part its type, its free-text description, word for word up to 120 characters, its format and number of pieces and whether the supplier has to produce the part or receives it ready-made, and also the scope of services and, for each country and each part, our internal number); we do not send names and contact details of the agency, the party it tenders for or its members, title, notes, return addresses, the codes of individual rows of the country list, the tender's files or the sender's address. We need the description of a part to match prices to the right part; if it contains a name, such as that of a campaign or of the party tendered for, that name is sent as part of the description. By default the requests go to Mistral's EU endpoint, which according to Mistral provides for processing in data centres in the EU and EFTA states. We store the result (a draft of a quote and the recognised text of the attachments) with the email.
The result is only a draft: we check it against the original email and attachments before it becomes a quote for the agency. No decision based solely on automated processing within the meaning of Art 22 GDPR takes place. The legal basis is our legitimate interest in capturing replies efficiently and with few errors (Art 6(1)(f) GDPR). Mistral processes the content as a processor under a data processing agreement.
Agency platform: reports of illegal content
If you report content on the agency platform that you consider illegal (Art 16 of Regulation (EU) 2022/2065) by email to our contact address (see above), we process your name, your email address and the content of your report with any attachments, in order to examine the report, confirm receipt and tell you our decision together with the possible means of redress. The legal basis is Art 6(1)(c) GDPR in conjunction with Art 16 of Regulation (EU) 2022/2065. For reports of offences under Arts 3 to 7 of Directive 2011/93/EU you do not have to give a name or an email address, but then we cannot reply to you.
Emails to this address are received and stored by Proton AG as our processor (see above under contact by email). If we then block a tender or a file, the agency concerned learns the reasons for the block and the facts we rely on; we do not give it your name or your email address. We store the reasons with the blocked tender or file for as long as the block stands, and delete them when the block is lifted; suppliers do not see them. We record every block and every lifting of a block in the server log with the time and the ID of the person who decided, without any details about the reporting person.
We keep your report, our replies and our correspondence on the matter in the mailbox for as long as the matter is open and for no more than three years after that, because we need them to establish or defend legal claims (Art 6(1)(f) GDPR).
Agency platform: export of the organisation
Owners of an organisation can request an export of all their data, in the workspace or through the API. From it we create a ZIP file with JSON files and the stored files as originals: supplier list with contacts, tenders with files, invitations, offers with PDFs, awards, comments, webhook addresses with delivery log, members and team invitations, details of the subscription and the incoming e-mails that we checked and handed over to the agency, with sender, subject, text, attachments, the result of the sender check and the draft of the automatic reading. Not included are hashes and secrets (keys, links, reply addresses, signing secrets), login data, e-mails that were not handed over, were discarded or could not be assigned, and the information which person in our office handled an e-mail. Of these e-mails we export all stored attachments, not only those that our office passed on to the agency with the e-mail. The export is free and needs no subscription.
For each export we store the organisation, the requesting member, whether it was requested in the workspace or with a key, the state, the size and the times. The ZIP file lies on our server in a directory of the organisation. Only owners of the organisation can download it, in the workspace or with a key that an owner created, and only for 7 days; then we delete the file. As soon as a newer export is ready, we also delete the files of the older ones, so only the newest is kept. The details of the export (without content) stay as long as the organisation exists. Encrypted backups of the server may contain the file until they are overwritten. The legal basis is Art 6(1)(b) GDPR or, for data we process on behalf of the agency, its instruction under Art 28(3)(g) GDPR.
Agency platform: background jobs and logs
Reminders before offer deadlines and about the subscription, the queries to Stripe, the delivery of webhooks, fetching attachments, reading replies and deleting expired emails, and most billing reports to our office, run as background jobs. Their log contains identifiers of tenders, invitations, organisations, members and emails, status, times and short error messages, but no email content, with one exception: the billing reports to our office that run as background jobs are in the log with their details (see the subscription section above). We also keep notes of which email has already been sent so that nobody receives it twice; the notes on emails to supplier contacts (such as invitations, reminders and result notices) are part of the sending we do on the agency's behalf; we keep the other logs under our own responsibility. If a background job ends with a final error, our office receives a summary email with the type, key, number of attempts and error text of the jobs concerned. We delete finished runs of the queries to Stripe and of webhook delivery 30 days after they finish, finished background jobs about the deadlines of tenders and the entries for billing reports to our office that have been sent 90 days after they finish, and the records of the summary notices to our office about failed jobs once they are 90 days old and the failure has been fixed (while a job is still failing, its record stays); the other logs and notes are not deleted automatically; we keep them for as long as the organisation exists: the notes on emails to supplier contacts on the agency's behalf, the other logs under our own responsibility, because we need them to fix errors and to document our background jobs (Art 6(1)(f) GDPR).
Cookies and storage on your device
When you submit a request, open an access link from one of our emails, or log in, we set a cookie called "nuxt-session" that secures your session, your login and your access to your requests; it is not set merely by visiting the website. It is encrypted, unreadable to scripts on the page, and valid for at most 30 days. If you change the language, we remember your choice, until you close the browser, in the cookie "mb_locale"; it sets the language of the pages that have a single address (login, your requests, confirmations); without this choice, they follow your browser's language setting. All other pages have their own address per language (such as /cs/… or /en/…) and always appear in the language of their address. In the request form you can choose to save a draft on this device; your entries then remain in your browser's storage (localStorage) and are restored the next time you open the form, until you submit the request, switch the option off, or start over. The draft itself is never sent to us. This storage is strictly necessary for the functions you requested (§ 165(3) TKG 2021). We do not use cookies for analytics or advertising.
Recipients
Your data is received, each only to the extent described, by: Hetzner Online GmbH (Gunzenhausen, Germany), on whose servers in Nuremberg the platform runs (encrypted backups are stored on Hetzner storage in Helsinki, Finland; the Hetzner Cloud backup function is also switched on for the server), and Sendinblue SAS (Brevo, Paris, France) for sending emails and Proton AG (Plan-les-Ouates, Switzerland) for receiving and storing emails sent to our addresses on mailingbid.com and salat.tech, all three as processors; the printers and lettershops from whom we source offers for your request or whom you commission; and, in the takeover case described above, the person named as the contact of the request; within the agency platform also Stripe Payments Europe, Limited (Dublin, Ireland) for subscriptions, as a processor and, for its own purposes such as fraud prevention and statutory verification duties, as an independent controller, and, where we have switched the function on, Mistral AI SAS (Paris, France) for reading replies as a processor; the suppliers an agency invites; the agency to which their quotes go; the other members of an organisation among themselves; and the systems whose webhook address an agency enters.
Brevo stores data in data centres in France and Belgium. Some of Brevo's sub-processors are located outside the EEA, in particular in the USA and India; insofar as data reaches them, Brevo relies on the adequacy decision for the EU-US Data Privacy Framework or on standard contractual clauses (Art 46(2)(c) GDPR). Emails to our addresses on mailingbid.com and salat.tech are received and stored by Proton AG, based in Switzerland; for Switzerland there is an adequacy decision of the European Commission (Art 45 GDPR). For the list of companies we write to by post, we use Notion (Notion Labs, Inc., USA) as a processor; according to Notion, transfers from the EU to the USA rest on standard contractual clauses (Art 46(2)(c) GDPR), which form part of Notion's data processing addendum. In handling subscriptions, data is transferred to Stripe, LLC in the USA; the basis is the transfer instruments agreed in the data processing agreement with Stripe (EU-US Data Privacy Framework or standard contractual clauses). Reading replies runs by default through Mistral's EU endpoint. The agency decides on the addresses for webhooks; where its system passes the events on and where that system is located is its decision, and it is also responsible for any transfer to third countries. Beyond this, we do not transfer any data to third countries.
Your rights
You have the right to access the data we process about you, as well as to rectification, erasure, restriction of processing and data portability (Art 15 to 18 and 20 GDPR). To exercise these rights, contact kontakt@salat.tech. You can also lodge a complaint with the Austrian Data Protection Authority (Barichgasse 40–42, 1030 Vienna, dsb.gv.at).
Right to object: You may object at any time, on grounds relating to your particular situation, to processing based on our legitimate interest (Art 6(1)(f) GDPR) (Art 21 GDPR).