Privacy Policy

1. Who we are

Gigdoor is operated by Felix Commerell, PickPost PK700509, Bahnhofquai 12, 4600 Olten, Switzerland (“Gigdoor”, “we”, “us”).

For any data protection question, write to info@gigdoor.app.

This policy explains how we handle personal data when you visit gigdoor.app, when you use Gigdoor as a venue, when you submit a booking request to a venue through a Gigdoor form, and when you write to a venue mailbox that the venue has connected to Gigdoor.

2. Our two roles

Please read this section first, because it determines who you should contact about your data.

We are the controller for:

• visitors to our website
• venue accounts and the people who use them
• people who contact us or request a pilot

We are a processor, not the controller, for:

• booking requests that artists and bands submit through a venue’s Gigdoor form
• email that reaches us because a venue has connected one of its own mailboxes to Gigdoor (section 4.6) — including email that turns out to have nothing to do with bookings

In those cases, the venue decides why and how that data is used. We store and process it only on the venue’s instructions, under a data processing agreement. If you are an artist and you want your submission corrected or deleted, contact the venue you applied to. The same applies if you wrote to a venue mailbox: the venue is the controller for that message, and it is the venue you ask. You can also write to us at info@gigdoor.app and we will forward your request to the venue and support them in handling it.

3. Applicable law

We are based in Switzerland and apply the Swiss Federal Act on Data Protection (FADP / revDSG). Where we offer our services to people in the European Economic Area, the GDPR also applies. Where this policy refers to a legal basis, this refers to Art. 6 GDPR; under Swiss law we rely on the corresponding justification.

4. What we process, why, and on what basis

4.1 Visiting the website

When you open gigdoor.app, our hosting provider automatically records technical data: IP address, browser type and version, operating system, the page requested, referrer, and the time of the request.

• Purpose: delivering the site, security, detecting and defending against attacks and abuse.
• Legal basis: legitimate interest (Art. 6(1)(f) GDPR) in operating a secure and functioning service.
• Retention: short-term server logs held by our hosting provider; we do not build long-term profiles from them.

4.1a Campaign measurement (our own marketing)

When you open gigdoor.app via a tracked link (for example a QR code with UTM parameters), we record that visit and subsequent views of selected public pages (such as the homepage, pricing and pilot request pages) in our own database. We store the UTM parameters, the page path, an anonymous visitor identifier, and a hashed form of your IP address (we never store the raw IP for this purpose). If you submit a pilot request while that attribution is still active, we link the same campaign data to your lead.

• Purpose: measuring how our own flyers and campaigns perform (scans, funnel steps, pilot sign-ups).
• Legal basis: legitimate interest (Art. 6(1)(f) GDPR) in understanding whether our marketing reaches the right venues.
• Retention: visit log entries are deleted after 90 days; pilot requests are kept as described in section 4.5.
• We do not use this data for advertising profiles, and we do not sell it.

4.2 Error monitoring

We use Sentry to detect technical errors in the application. When an error occurs, Sentry receives technical data about the request and the state of the application.

• We configure Sentry so that it does not send user identifiers or IP addresses (sendDefaultPii: false, IP scrubbing enabled).
• Purpose: finding and fixing faults.
• Legal basis: legitimate interest (Art. 6(1)(f) GDPR) in a stable and secure service.
• Retention: deleted according to Sentry’s retention period, by default 90 days.

4.3 Venue accounts

To use Gigdoor as a venue you provide an email address and a venue name. We also store your settings, reply templates, and records of sign-ins.

We use passwordless sign-in: we send a one-time sign-in link to your email address.

• Purpose: providing the service, authentication, account security, support.
• Legal basis: performance of a contract (Art. 6(1)(b) GDPR).
• Retention: for the duration of the contract, then deleted within 30 days of account closure, subject to statutory retention periods for accounting records.

4.4 Pilot requests and contact

If you request a pilot or contact us through a form or by email, we process the details you give us: name, email address, venue name, and the content of your message.

• Purpose: replying to you, arranging setup, pre-contractual steps.
• Legal basis: pre-contractual measures and performance of a contract (Art. 6(1)(b) GDPR), otherwise legitimate interest (Art. 6(1)(f) GDPR) in responding to enquiries.
• Retention: 12 months after the last contact if no contract results, unless correspondence obligations require longer.

4.5 Booking requests submitted by artists

When an artist submits a booking request through a venue’s Gigdoor form, we process, on behalf of that venue: band or artist name, contact email address, optionally a phone number, expected audience size, genres, proposed dates, a description of the act, links to profiles and music, and a free-text message. We also process the status, internal notes and reply emails that the venue adds afterwards.

• Controller: the venue that owns the form.
• Our role: processor, acting only on the venue’s instructions under a data processing agreement.
• Retention: determined by the venue. The venue can delete a request at any time. When a venue account is closed, we delete the associated booking requests within 30 days.

4.6 Connected mailboxes: email forwarded to Gigdoor

A venue can connect one of its own mailboxes — usually its booking@address — by setting a forwarding rule in its own mail service that points at a Gigdoor address reserved for that venue. Where a venue has done this, we receive a copy of every message sent to that mailbox, not only booking requests. A forwarding rule does not filter, and whether a message is a booking request is precisely the question we are answering. Newsletters, invoices, out-of-office replies and private messages sent to that address therefore reach us too. If you wrote to such a mailbox, you may never have had any dealings with Gigdoor at all, and this section is the part of this policy that concerns you.

We have no access to the venue’s mailbox. We cannot read, move, mark or delete anything in it, we never reply to an incoming message automatically, and we never generate a bounce — so nobody learns from Gigdoor whether an address exists. The venue switches the forwarding on and off in its own mail service, without us.

For each forwarded message we process:

• sender address, sender name, reply-to address and subject
• the full message content — the HTML part, the text part and the technical headers
• metadata about attachments: filename, file type, size and the identifier the email provider uses for the file. We do not store attachments themselves. When someone at the venue opens an attachment, we request a short-lived link from the email provider at that moment and pass the file through without keeping a copy. That works for as long as the email provider keeps the message, currently 30 days from receipt; after that the venue reads the attachment in its own mailbox.
• what our own processing produced: the classification, how confident the model was, which filter rule matched, and the booking details extracted from the message

What we do with it. A rule-based filter first removes obvious bulk mail (mailing-list headers, automatic replies) without any model being involved. Everything else is classified by an AI model as a booking request, follow-up correspondence, unclear, not a booking request, or spam; for the first two, a second model reads the message and extracts the booking details. Both models run at Infomaniak Network SA in Switzerland (section 6). The models receive the subject, the message text, the sender’s address and name, and the filename, type and size of any attachment. They never receive the attachment files themselves, and they never receive the technical headers. Message content is treated as data and never as an instruction: if a message contains text trying to instruct an automated system, that is reported to the venue as a flag and changes nothing about how the message is handled.

A person decides, always. An extracted request does not become a booking request in the venue’s dashboard on its own. Someone at the venue sees what was extracted next to the original message, corrects it where it is wrong, and confirms or rejects it. Nothing is filed, answered or rejected automatically (section 10). A message we classify wrongly is not lost either: the venue’s own mailbox still has it, unchanged.

The one email we may send to you. If the message is missing the details the venue needs, a person at the venue can click to ask for them. That email goes only to the reply-to or sender address stored on the message we received — never to an address read out of the message text, and never automatically. It contains a link to the venue’s booking form with the band name, contact name, contact email address and genre already filled in, so those values appear in the link and therefore in the server logs of our hosting provider. We send no other email to anyone who writes to a connected mailbox.

How long we keep it. Message content is kept for a period that depends on what the message turned out to be. We deliberately keep the shortest for the mail we never asked for:

Deleting means that the message content — the HTML part, the text part, the headers, the attachment metadata, the extracted details and any stored error text — is removed from the record. We deliberately keep the sender, the subject, the time of receipt and our classification of the message, together with a note of what the person at the venue decided. That is what lets a venue answer the question “what happened to that message” about a message whose content we have correctly already deleted, and it is what our monthly volume counters are based on. Where a message was proposed as a booking request, its text becomes part of that request and is then kept like any other booking request (section 4.5) — including while the request is still waiting for someone at the venue to confirm it.

Three limits on this, stated because they are real. The periods above are the periods of our copy: the email provider keeps its own copy of the received message, its headers, its body and its attachments for 30 days from receipt and gives us no way to delete it earlier, so a message we empty after 24 hours still exists there for the rest of that month (section 7). Deleted message content can also still exist inside our database provider’s backup and point-in-time-recovery window until that window has passed. And a venue may agree with us in writing to keep everything for 30 days for a limited period while the system is being set up, so that the quality of the classification can be measured; we never switch that on without that written agreement, and it can only lengthen the periods above, never shorten them.

• Controller: the venue that connected the mailbox.
• Our role: processor, acting only on the venue’s instructions under a data processing agreement.
• If you wrote to such a mailbox and want to know what happened to your message, or want it deleted, contact the venue. Write to us at info@gigdoor.app if you cannot reach them and we will support the venue in answering.

4.7 Emails we send

We use Resend to send transactional email: sign-in links, submission confirmations to artists, the accept or decline replies that venues send from Gigdoor, and the request for missing details described in section 4.6. Resend processes the recipient address and the content of the message in order to deliver it. Where a venue has connected a mailbox, Resend is also the service that receives the forwarded messages for us and holds them, including their attachments, for 30 days (sections 6 and 7).

5. Cookies and similar technologies

We use the following cookies and similar storage:

• a session cookie to keep venue users signed in
• a language preference stored in your browser
• campaign attribution cookies (anonymous visitor id and first-touch UTM parameters, up to 30 days) when you arrive via a tracked marketing link — see section 4.1a

We do not use third-party advertising cookies, tracking pixels, or cross-site profiling. We do not sell data to advertisers.

6. Who we share data with

We do not sell personal data and we do not share it for advertising.

We use the following processors, each bound by a data processing agreement:

Beyond this, we disclose data only where we are legally required to, or where it is necessary to establish, exercise or defend legal claims.

7. Transfers outside Switzerland and the EEA

Some of our providers are based in the United States. Where data is transferred there, we rely on the European Commission’s Standard Contractual Clauses together with the Swiss addendum recognised by the Federal Data Protection and Information Commissioner, and, where the provider is certified, on the EU-US Data Privacy Framework and its Swiss extension. You can request a copy of the relevant safeguards at info@gigdoor.app.

Email forwarded from a connected mailbox is affected by this, and we say so plainly because it is the processing with the broadest reach. The forwarding address is configured to receive in Ireland, so a forwarded message arrives in the EEA — but Resend then stores the received message, its headers, its body and its attachments in the United States, together with the associated metadata, delivery logs and API records. Resend confirmed this to us in writing on 8 October 2026. We therefore treat the receipt of forwarded email as a transfer to the United States and rely on the safeguards named above for it; Resend relies on the Standard Contractual Clauses in its own data processing agreement, with the EU-US Data Privacy Framework as a supplementary mechanism, and its agreement covers received email on the same terms as sent email. Our database, in which the message is then stored and from which it is deleted on the schedule in section 4.6, is in Germany.

One limitation we cannot engineer away, and will not hide. Resend keeps a received message — headers, body and attachments — for 30 days from receipt and then removes it, and it currently offers no way for us to delete a received message earlier, neither through its dashboard nor through its API (confirmed in writing on 8 October 2026; a feature request is open). So if you ask us to delete a forwarded email, we delete our own copy on request — which is the copy anything in Gigdoor is read from — but Resend’s copy expires on its own 30-day clock and no sooner. We will say so again if you ask, rather than report a deletion we cannot complete.

Classification of forwarded email and the extraction of booking details from it are carried out in Switzerland, by Infomaniak Network SA. That processing involves no transfer outside Switzerland.

8. Security

We use TLS encryption for all data in transit, encryption at rest for our database, passwordless authentication with expiring one-time links, strict separation of data between venues, access controls limiting access to what is necessary, and automated backups. No system is completely secure, but we treat unauthorised access to venue and artist data as the most serious failure this service could have.

For forwarded email specifically: the content of a message is never rendered as HTML anywhere in the product, only as plain text, so a message cannot run anything in a venue’s browser; attachment files are never stored by us; and message content and sender addresses are kept out of our application logs rather than only being masked in them.

9. Your rights

You have the right to access your data, to have inaccurate data corrected, to have data deleted, to restrict processing, to object to processing based on legitimate interest, and to receive your data in a portable format. Where processing is based on consent, you may withdraw it at any time with effect for the future.

To exercise these rights, write to info@gigdoor.app. We may need to verify your identity.

What a deletion reaches, and what it does not. If your data came to a venue as a forwarded email, we delete our own copy on request — the copy everything in Gigdoor is read from. The email provider’s copy of the received message is kept for 30 days from receipt and it offers us no way to delete it earlier, so that copy expires on its own clock and no sooner (section 7). We will tell you this rather than report a deletion as complete while that copy exists, and we will tell you when it expires.

If you submitted a booking request to a venue, contact the venue first, since they are the controller for that data. If you cannot reach them, write to us and we will help.

You also have the right to lodge a complaint with a supervisory authority:

• Switzerland: Federal Data Protection and Information Commissioner (FDPIC), Feldeggweg 1, 3003 Bern, www.edoeb.admin.ch
• EEA: the supervisory authority of your country of residence

10. Automated decision-making

We do not use automated decision-making or profiling that produces legal effects for you. Filtering and sorting inside a venue’s dashboard is performed by the venue, not by us, and does not automatically decide anything.

Where a venue has connected a mailbox (section 4.6), each forwarded message is classified automatically and, where it looks like a booking request, booking details are extracted from it automatically. This is not a decision within the meaning of Art. 22 GDPR, and the reason it is not is worth stating rather than asserting: a person at the venue sees every extracted request and confirms or rejects it before it becomes a request at all. The automated step sorts messages and fills in a form; it decides nothing about anybody, it sends nobody a rejection, and a message it classifies wrongly stays in the venue’s own mailbox unchanged. If we ever remove that human confirmation step, this section has to change with it, and we will update this policy before doing so.

11. Children

Gigdoor is intended for professional use by venues and by artists who are able to enter into agreements. It is not directed at children.

12. Changes to this policy

We may update this policy as the service develops. The current version is always available at gigdoor.app/en/privacy. Where a change materially affects you, we will notify venue account holders by email.