Privacy policy

Last revised 2026-09-05

1. Who we are

microdoseoffice (the “service”) is the web application at https://www.microdoseoffice.com. It is operated by Revolt NV, Brechtsebaan 30, 2900 Schoten, Belgium, enterprise number 0541.517.346 (“we”), which is the controller for the data described in sections 3, 5, 6 and 8 and the processor, on behalf of your organisation, for the data described in section 4. For anything in this policy you can reach us at arne@revolt.be.

2. What this policy covers

This policy describes what personal data the service processes, why, for how long, and who can see it. It covers the signed-in application (the organisation workspaces and the artist portal), the pages that are reachable without an account (this page, the homepage, the terms of service, the questionnaire and document-download links that are e-mailed to people who have no account, and the supplier-document upload described in section 6) and, in section 5, the optional Google Calendar integration.

3. Accounts and organisations

Sign-in, sessions, organisations and invitations are provided by Clerk, our identity provider. When you sign in or are invited into an organisation, Clerk processes your name, e-mail address and sign-in credentials. Clerk sends us notifications about users, organisations and memberships, which we copy into our own database so that access rules can be enforced there; the notifications themselves are also kept in a ledger for troubleshooting. Your organisation’s administrators decide who is a member and which modules each member can use.

We process this data because it is necessary to provide the service to your organisation under its agreement with us (Article 6(1)(b) GDPR). Security measures, rate limiting and error monitoring (section 8) rest on our legitimate interest in running the service safely (Article 6(1)(f)). The Google Calendar integration runs only with your consent, which you can withdraw at any time (section 5.6).

4. Data your organisation enters

Everything an organisation records in its workspace — bookings, artists, promotors, venues, contacts, documents, files, ticket and cashless revenue, budgets — belongs to that organisation and is only visible to its members, according to the module access its administrators grant. We process it to provide the service to that organisation, on its instructions. This includes data the organisation imports from the systems it already uses: the Revenue Analytics module imports ticket orders, including the buyer’s name and contact details, from the organisation’s ticketing provider, and the Budget & Cashflow module imports supplier and spend records, including the names of the organisation’s own staff who made the spend, from its spend-management provider (section 7 names them). Every organisation has an audit log of who changed what. In the Booking module, deleted records are marked as deleted and kept, so they can be restored from that module’s audit log for seven days, rather than being erased; the other modules do not offer a restore.

5. Google Calendar integration

Members of an organisation’s Booking module — booking staff and the artists invited into the artist portal — can connect their own Google account so that bookings appear in their own Google Calendar. This is optional, it is started by you on the calendar screen, and Google asks for your consent on its own screen before anything is connected. Nothing in this section applies until you connect.

5.1 What we ask Google for

We request exactly these four permissions, and never more:

If you untick the calendar-events permission on Google’s consent screen, the connection is not stored: we immediately ask Google to revoke the grant and show you a message instead.

5.2 What we store

• The e-mail address and the stable account identifier of the Google account you connected, when you connected it, and the list of permissions Google actually granted.
• Your calendar choices: which calendar receives bookings, which calendars feed the overlay (their id, name and colour as they were when you chose them), whether your own calendar should receive all of your organisation’s bookings, and which of those overlay calendars you have hidden from view in the calendar rail (their ids only, kept with your other view preferences rather than with the connection).
• The OAuth refresh token Google issued, the current short-lived access token and its expiry time. These are what let the service write to your calendar in the background when a booking changes.
• For every booking event the service created in your calendar: the Google event id and the calendar it was written to. This ledger is what lets the service update or remove its own events later.
• Two entries in your organisation’s audit log: that you connected Google Calendar (with the connected e-mail address) and that you disconnected it.

5.3 What we do not store

• The contents of your calendar. Your own events are fetched from Google for the month you are looking at, shown only to you as a read-only overlay in the agency calendar, and discarded; they are never saved on our side.
• Any other Google data: no contacts, no mail, no files, no profile information beyond the e-mail address and account identifier above.

5.4 What we write to your calendar

The service creates one all-day event per booking in the one calendar you chose, keeps it up to date when the booking changes, and removes it when the booking is cancelled or deleted. Each such event carries a private marker identifying it as created by microdoseoffice, and when the service re-checks your calendar it only lists events carrying that marker. The only events it reads that it did not create are your own events for the month you are viewing, as described in section 5.3. It never edits or deletes an event it did not create.

5.5 How the tokens are protected

Refresh and access tokens are stored in a dedicated database table that no signed-in session can read: the table has no access policy for application users at all, and only server-side code holding the service credential can reach it. Tokens are never sent to your browser, never included in a page, and never written to logs or error reports. All requests to Google are made server-side over HTTPS. The database that holds the table is encrypted at rest and in transit by the database provider (section 8); we do not add a separate application-level encryption layer to the token table beyond those protections.

5.6 How long we keep it, and how to delete it

Everything in 5.2 except the hidden-calendar view preference is kept for as long as your connection exists. Access tokens are replaced as they expire. The connection ends in one of these ways:

• Disconnect in the app (the calendar screen or the artist portal). The service removes the events it created from your calendar, asks Google to revoke the refresh token, and deletes the event ledger, the connection record and the token record. If the token is no longer valid at that moment (for example because you already revoked access at Google), the events cannot be removed and stay in your calendar; everything else is still deleted. The two audit-log entries remain part of your organisation’s audit history.
• Deleting your account. The same disconnect runs automatically when your user account is deleted.
• Revoking at Google. You can withdraw access at any time in your Google account’s third-party access settings. Syncing then stops and the stored token stops working; the stored records are removed the next time you disconnect in the app, or on request to us.
• Leaving an organisation. When you are removed from an organisation, the events the service created for that organisation’s bookings are removed from your calendar. Your connection itself remains for any other organisation you belong to. If you no longer have Booking access anywhere, the disconnect control is not shown; revoke at Google or contact us and we will remove the stored connection.

5.7 Sharing, and what we never do with Google data

Google user data is processed only on the infrastructure that runs the service (see section 7) and only to provide the calendar integration described here. It is not shared with any other party, not sold, not used for advertising, not used to build profiles, and not used to develop, train or improve any machine learning or artificial-intelligence model. No person reads your calendar data: the service does not store it, and access to the database that holds the connection records is limited to the operator, for security, abuse investigation and troubleshooting, or with your consent.

microdoseoffice’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

6. Supplier documents

An organisation can collect the tax documents its non-resident suppliers owe it through a public upload page of its own (no account, no sign-in). A supplier who uploads there provides the document itself — typically a tax-residence certificate or withholding-tax form carrying the supplier’s name, address, tax identification number and signature — and the name and contact details the form asks for. What happens to it:

• The documents are stored in private file storage that no signed-in session can read, and are filed into the organisation’s own Google Drive so that its finance team can work with them.
• Before the confirmation is issued, the documents are checked automatically against a fixed list of document checks by an artificial-intelligence service (Anthropic, section 7). The checker answers only those checks; its notes are stored with the dossier and printed on the confirmation. The documents are sent for that one check and nothing else, and the check never blocks an upload: if it cannot run, the confirmation says so.
• The upload page keeps usage records (which step was reached, with what outcome) for year-over-year statistics. The supplier’s name in those records is removed once 90 days have passed since the session’s last activity; the records themselves carry no document contents.

7. Who processes data on our behalf, and who else receives it

These providers process personal data on our behalf and on our instructions (our sub-processors). The list was checked against the production system on 2026-09-05; a provider is listed only when the service actually sends it personal data.

• Clerk — sign-in, sessions, organisations, invitations and the notifications about them that we mirror into our database.
• Supabase — the database and the file storage, hosted in the European Union (Ireland), including the Google Calendar records in section 5.
• Vercel — hosting of the web application (server functions in Ireland), its firewall and bot protection, and its web analytics and speed insights.
• Sentry — error monitoring for the application. An error report carries your user id, your organisation's id, the page address and the technical context of the failure; request bodies, cookies and authorisation headers are stripped before it leaves the application, and tokens and calendar contents are never included.
• Upstash — the store behind rate limiting, which holds short-lived counters keyed by IP address or user id (Ireland).
• Google Cloud — our own document renderer, which turns the contract or itinerary the application sends it into a PDF and returns it without keeping a copy (Belgium region), and the Google Drive API through which supplier documents (section 6) are filed into the organisation's own shared drive.
• Anthropic — the artificial-intelligence service that performs the fixed document check on uploaded supplier documents (section 6), one call per dossier, under Anthropic's commercial API terms.
• GitHub — runs our scheduled import jobs on its hosted runners: the ticket-order import from your organisation's ticketing provider and the spend import from its spend-management provider pass through a job there on their way into our database; job output is scrubbed of personal data and credentials.

These recipients decide for themselves how they process what they receive, and are not our processors:

• Google (Google Calendar) — only for accounts that connected the integration in section 5: the booking events the service writes into your own Google Calendar are processed by Google under your own Google account and Google's own privacy policy.
• Ticketing and cashless providers — the providers your organisation already uses sell the tickets and run the cashless system under their own terms; the Revenue Analytics module imports the sales and transaction data your organisation authorises it to fetch from them. Nothing is sent back to them.
• Spendesk — when your organisation connects its Spendesk account, the Budget & Cashflow module imports its spend and supplier data. Nothing is sent back to Spendesk.

Our database, file storage, server functions and rate-limit store run in the European Union (Ireland). Some of the providers above are established in the United States; where they process personal data outside the European Economic Area, we rely on the transfer safeguards in that provider’s data processing terms (standard contractual clauses or an adequacy decision). We do not sell personal data and we do not share it with anyone else, except where the law requires it.

8. Technical data and security

Requests to the questionnaire and document-download links, to the supplier-document upload (section 6) and to the Google connect flow are rate limited by IP address and, for the Google connect flow, by user id; the counters live only for the length of the rate-limit window. This page, the homepage and the terms of service are not rate limited by the application. Errors are reported to our error monitoring with your user id, your organisation’s id, the page address and the technical context of the failure; request bodies, cookies and authorisation headers are stripped before an event leaves the application, and tokens and calendar contents are never included. Page views and performance measurements are collected in aggregate by our hosting provider’s analytics, without a user identifier.

All data is transmitted over TLS, and the database and file storage are encrypted at rest and in transit by our database provider. We do not currently apply an additional, application-level field encryption of our own on top of that. Access to the database is limited to server-side code holding the service credential and to the operator, and every tenant table is protected by row-level access rules keyed to your organisation.

9. How long we keep data, and what happens when an organisation leaves

• While your organisation uses the service: the data in section 4 is kept for as long as the organisation keeps it; the audit log is kept for the life of the organisation.
• Your account: when your user account is deleted, your profile is marked as deleted and the Google Calendar connection is closed (section 5.6). Your name and e-mail address remain in the audit entries and notification ledger that recorded your actions, so the organisation’s history stays intact.
• When an organisation’s agreement ends: access ends at once — the organisation is removed from our identity provider, every membership and pending invitation ends with it, and the workspace can no longer be opened by anyone. The organisation’s data is not erased at that moment: it remains stored, marked as belonging to a deleted organisation and inaccessible to any user, until it is deleted. During the 30 days after termination the organisation may ask us for an export of its data. We do not currently delete a terminated organisation’s data on a fixed schedule; we delete or anonymise it when the organisation asks us to, or at our own initiative once we no longer have a reason to keep it, and this page will say so before a fixed schedule is introduced.
• Backups: once data has been deleted, remaining backup copies held by our database provider expire through its normal backup cycle, no later than 90 days afterwards.
• Records we must keep: invoices, payment records and the evidence we are required to keep are retained only where and for as long as Belgian law requires.

10. Your rights

You can ask us to access, correct, delete or restrict the personal data we hold about you, to object to processing that rests on our legitimate interest, and to receive the data you gave us in a portable form; you can withdraw the Google Calendar connection yourself at any time as described in 5.6. Where we act as your organisation’s processor (section 4), we pass your request to the organisation, which decides on it, and organisation administrators manage membership and module access within their own organisation. Requests go to arne@revolt.be. You also have the right to lodge a complaint with a supervisory authority, in Belgium the Belgian Data Protection Authority (Gegevensbeschermingsautoriteit / Autorité de protection des données).

11. Changes to this policy

When this policy changes, the revision date at the top changes with it. If the Google Calendar integration ever asks for different permissions, Google will ask for your consent again and this page will describe the change first.