GigDex Privacy Policy

Effective date: 2026-05-25 Last updated: 2026-05-25 Operator: Aloura Entertainment Ltd (trading as GigDex), United Kingdom

1. Introduction

This Privacy Policy explains how GigDex ("the Service", "we", "us", "our") collects, uses, stores, and protects your personal data when you use GigDex at https://gigdex.co.uk and any related sub-domains.

GigDex is a booking management platform for music, entertainment, and events agencies. It is designed for agency operators and the artists/crew/clients they work with.

GigDex is operated by Aloura Entertainment Ltd, a company registered in England and Wales (Companies House number 16338729). For the purposes of UK GDPR, Aloura Entertainment Ltd is the legal entity acting as data controller / processor as detailed in §3.5. Throughout this policy, references to "GigDex", "we", "us", or "our" mean Aloura Entertainment Ltd acting in its capacity as operator of the GigDex service. Full contact details are in §11.

By using GigDex, you agree to this Privacy Policy. If you do not agree, please do not use the Service.

2. Information we collect

We collect the following categories of personal data:

2.1 Account information

When you sign up:

Name
Email address
Encrypted password (we never store plain-text passwords)
Business name + company details (e.g., company number, VAT number, address)
Billing details (collected by our payment processor, Stripe — we don't see card numbers)
Subscription tier + status

2.2 Business operational data

Data you enter into GigDex to operate your agency:

Client records (name, email, phone, address)
Artist / crew / band records (name, contact details, banking details, photos)
Booking records (dates, venues, performers, fees, notes)
Invoices, quotes, contracts, payouts
Custom email templates + business settings

2.3 Google account data (when you connect Gmail and/or Drive)

If you choose to connect your Google account via the in-app integration, we receive and store the following data:

OAuth refresh + access tokens — encrypted at rest using AES-256-CBC via Laravel's encrypted cast (key managed separately from the database). Used to authenticate API requests on your behalf.
Your authenticated Google email address — stored so we can show you which Gmail account is connected.
Google Drive file + folder IDs — stored as references to PDFs and folders the Service has created in your Google Drive (invoice PDFs, payout PDFs, signed contract PDFs). We do not store the file content; the actual files live in your Drive.

In addition, when the Service queries the Gmail or Drive APIs to perform its functions, the API responses may transiently include:

For Gmail: metadata about email threads the Service has previously sent or drafted on your behalf — including thread IDs, message IDs, label IDs (e.g., the "SENT" label), and message headers returned by the Gmail API's metadata format. We use this only to determine whether an email we sent appears in your Sent folder and to keep our local "sent / drafted" status in sync; we do not store the headers or thread structures persistently.
For Drive: metadata about files and folders the Service has previously created — including file name, MIME type, parent folder, creation timestamp, file size. We use this to update/replace existing files (rather than creating duplicates) and to show you a link to the Drive folder; we do not store this metadata persistently other than the file/folder ID references noted above.

We do NOT receive, store, or retain:

Your Gmail inbox contents, your Gmail message bodies, or messages we did not send or draft
Your Gmail folders or labels other than the structural metadata above for our own threads
Drive files we did not create — the drive.file scope we request grants access only to files created by this application
Your Google profile photo, contacts, calendar, or any other Google data

2.4 Email content you compose

When you send invoices, quotes, or other emails via the Service:

Email body, subject, recipient address, and any CC/BCC addresses are stored in our database as a record of what was sent
This content is YOUR content, composed by you (often from templates you customised). It is not data we retrieved from Google.

2.5 SMS content you compose

If you enable SMS via the Twilio integration:

SMS body, recipient phone number, and delivery status are stored as a record
We use your own Twilio account credentials (encrypted at rest) to send on your behalf

2.6 Technical + usage data

IP address (for security + rate limiting)
Browser type + device type
Authentication session timestamps
In-app activity (which pages you visited, when) — only if Sentry error monitoring is enabled

2.7 Cookies

We use only essential cookies:

Laravel session cookie (laravel_session) for authentication
CSRF token cookie (XSRF-TOKEN) for security
Optional "remember me" cookie if you check that box at login

We do NOT use third-party advertising cookies, tracking cookies, or analytics cookies (no Google Analytics, Facebook Pixel, etc.).

3. How we use your data

3.1 To provide the Service

We use the data above only to operate GigDex's features. Specifically:

Account information: authentication, billing
Business operational data: render the booking management UI, calculate payouts, generate invoices
Google account data: send emails from your Gmail address (when you choose to), upload invoice/payout PDFs to your Drive (when you choose to)
Email/SMS content: send messages on your behalf + maintain a record so you can review past correspondence

3.2 Specifically how Google account data is used

GigDex requests the following Google OAuth scopes when you click "Connect Gmail" (the in-app button grants all four scopes together, as the same OAuth connection covers both Gmail features and the optional Drive backup):

| Scope | Why we use it | What we read | What we write | |---|---|---|---| | gmail.send | Send (a) operator-triggered emails from your Gmail address — invoices, quotes, contracts, signed contract copies, availability offers, booking reminders, payout-paid notifications, and other manually-sent operational emails composed from templates you control; and (b) automated integration-health alerts to your registered notification address when the Service's nightly health check detects a critical issue (e.g., expired OAuth token, failed background job) that requires your attention. Both surfaces send from your own Gmail account so recipients see the email as coming from you, not a third-party noreply. | (nothing) | Outbound emails (composed by you from templates you control; integration-health alerts use a fixed internal template addressed only to your own registered notification email) | | gmail.compose | Create email drafts in your Drafts folder so you can review/edit before sending; check whether a draft still exists; delete drafts you've cancelled; send a previously-saved draft | Existence of specific draft IDs the Service created | Email drafts (composed by you from templates), and deletion of drafts you cancel | | gmail.readonly | Determine whether emails the Service sent on your behalf appear in your Sent folder, and detect when you've sent a draft yourself from Gmail's UI (so our in-app "sent / drafted" status stays accurate). Used by an in-app scheduled task that periodically queries thread metadata for threads the Service has previously sent/drafted. Once-only on initial connection, we also call users.getProfile to retrieve your authenticated Google email address | Thread + message metadata (IDs, labels including "SENT", thread structure, and message headers as returned by Gmail API format=metadata) for threads the Service previously created. We do not retrieve message bodies, do not crawl your inbox, and do not access threads we did not initiate | (nothing) | | drive.file | Upload + update invoice PDFs, payout PDFs, and signed-contract PDFs to a /GigDex/Finance/... folder structure in your Drive for backup + sharing. Delete or archive files when underlying records change. Read folder/file metadata (name, parent, MIME type, timestamps, size) to manage the Service-created folder structure | File + folder metadata for files the Service has created in your Drive (name, parent folder, MIME type, timestamps, size) | PDF files in the /GigDex/... folder structure we create, plus folder creation, updates, and (where you configure) deletes or archives |

The drive.file scope is intentionally narrow — it grants access ONLY to files that the Service itself creates. We cannot read, modify, or delete any file in your Drive that GigDex didn't create. The complete folder structure created by the Service is rooted at /GigDex/ in your Drive; you can view it in Drive's UI under that folder.

3.3 Limited Use disclosure (Google API Services User Data Policy)

GigDex's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Specifically, this means:

We only use Google user data to provide or improve user-facing features that are prominent in our app's UI (Gmail email sending, Drive PDF backup).
We do not allow humans to read your Google user data unless: (a) you give us explicit written consent (e.g., for support), (b) we are investigating a security incident or potential abuse, or (c) we are required by law.
We do not transfer Google user data to third parties other than:
- Subprocessors strictly necessary to provide the Service (our hosting provider Hetzner Cloud, our error-monitoring provider Sentry — see §5)
- Where required by law
We do not use Google user data for serving advertisements, including retargeting, personalised, or interest-based advertising. We don't serve ads at all.
We do not use Google user data to train AI / ML models.

3.4 Lawful basis for processing (UK GDPR Article 6)

Each category of personal data processing has a lawful basis under UK GDPR Article 6. This table sets out the basis for each purpose:

| Processing purpose | Lawful basis | Notes | |---|---|---| | Operating your account (authentication, settings, subscription) | Contract (Art. 6(1)(b)) | Necessary to perform the SaaS contract with you | | Billing + subscription management (via Stripe) | Contract (Art. 6(1)(b)) | Necessary to provide paid Service | | Storing your business operational data (clients, artists, bookings) | Contract (Art. 6(1)(b)) | This is the Service you are paying for | | Sending emails / SMS / notifications on your behalf (when you enable) | Contract (Art. 6(1)(b)) | Feature you opted into | | Google Drive / Gmail integration data (OAuth tokens, sync state) | Contract (Art. 6(1)(b)) | The Google integration is an opt-in feature of the paid Service that you contracted for. GigDex processes the tokens and sync state as part of providing that feature on your instructions. Disabling the integration (via Settings > Integrations > Disconnect — see §7.1) is treated as switching off an optional feature, not as withdrawal of GDPR consent, and does not affect the rest of the Service. | | Multi-tenant security (tenant isolation, access logging, sub-agent restrictions) | Legitimate interests (Art. 6(1)(f)) | Necessary to protect all users of the Service; balanced against minimal data scope | | Fraud + abuse prevention (rate limiting, error monitoring) | Legitimate interests (Art. 6(1)(f)) | Necessary for Service security; data minimised | | Financial record-keeping (invoices, payment records) past account closure | Legal obligation (Art. 6(1)(c)) | UK Companies Act / HMRC retention requirements (typically 7 years) | | Service improvement + debugging (when Sentry is enabled in production) | Legitimate interests (Art. 6(1)(f)) | Stack traces only; no body content of emails or messages |

You can disable the Google integration at any time without affecting the rest of your Service usage. Other lawful bases are tied to the Service itself; ending them means closing your account.

3.5 Controller / processor positioning

GigDex processes personal data in three distinct capacities, and UK GDPR treats these roles differently. In each case the legal entity acting in the stated capacity is Aloura Entertainment Ltd (the operator of GigDex, see §1):

GigDex is the data controller for your account data and your direct relationship with us — your name, email, login credentials, business settings, subscription/billing details, security logs, and technical telemetry necessary to operate the platform. We decide the purposes and means of this processing.
GigDex is the data processor for the personal data you upload about third parties — your clients' names + emails + addresses, your artists' contact + banking details, your crew's contact details, the contents of emails/SMS messages you compose and send via the Service, and any other content you store in GigDex. You are the controller for that data. You are responsible for: (a) having a lawful basis to upload it to GigDex (typically your own contract or legitimate interest with the third party), (b) responding to data subject rights requests from those third parties (we will assist as your processor — see §7), and (c) providing appropriate privacy notices to the individuals whose data you upload.
GigDex is the data processor for the Google integration data processed on your instructions — specifically the contents of emails the Service sends or drafts via your Gmail account on your behalf, and the PDFs the Service uploads to your Drive on your behalf. You instruct the Service to perform these actions; the Service uses your own Google credentials to act on those instructions. We hold and use the underlying OAuth refresh and access tokens as service credentials to carry out those instructions; we do not use the tokens for any independent purpose of our own.

If you require a formal Data Processing Agreement (DPA) for the third-party data and Google integration data we process on your behalf, contact [email protected].

3.6 Special category data ("sensitive personal data")

GigDex's data model includes one structured field plus several free-text fields that may capture special category data under UK GDPR Article 9 (health, religion, philosophical beliefs, etc.):

dietary_requirements on artist records — an optional structured field for recording dietary needs for catering at gigs. Depending on the contents, this field can reveal health information (allergies) or religious/philosophical beliefs (e.g., kosher, halal, vegan-for-faith reasons).
special_requirements on bookings — a free-text field whose placeholder text suggests dietary restrictions but which you may use to record any catering, accessibility, medical, or religious requirements relating to a booking.
notes on booking requirements, and other free-text notes / performance_notes fields elsewhere in the data model — these are unrestricted text fields and could in principle contain any information you choose to record, including special-category data.

We do NOT routinely process special category data, and we do not analyse free-text fields for sensitive content. We treat the structured dietary_requirements field and the free-text fields above with the same encryption and access controls as other operational data, and we display them only on the booking, gig-ticket, and operational views where they are needed.

You (as the controller for the third-party personal data you upload — see §3.5) are responsible for: (a) limiting what you write into free-text fields to what is operationally necessary; (b) where you record information that falls into a UK GDPR Article 9 special category, obtaining the data subject's explicit consent under Art. 9(2)(a) (or relying on another Article 9 condition that applies in your circumstances) before entering it into GigDex; and (c) providing appropriate privacy notices to the individuals whose data you upload.

If you require guidance on whether a specific use of these fields is appropriate under UK GDPR, please obtain your own legal advice — we cannot give it.

4. How we store + secure your data

4.1 Where data lives

GigDex's production servers are hosted on Hetzner Cloud (Germany, EU). Daily encrypted backups are stored on Cloudflare R2 (multi-region object storage). Both providers are GDPR-compliant.

4.2 Encryption

In transit: All connections to GigDex use HTTPS / TLS 1.2+. The site uses a Let's Encrypt SSL certificate auto-renewed by Forge.
At rest (database column-level): The following sensitive fields are encrypted at rest using AES-256-CBC via Laravel's encrypted cast (encryption key stored separately from the database):
- User passwords (hashed via bcrypt, not encrypted — irreversible)
- Gmail OAuth access + refresh tokens
- Spotify OAuth tokens (if you use the Spotify integration)
- Twilio account credentials (if you provide your own)
- Stripe API keys (the client-payments integration; not the GigDex subscription billing keys)
- Banking details (account number, sort code, IBAN, BIC) on artist/crew/agency profiles
At rest (server filesystem): PDF files generated by the Service (invoices, payouts) are stored on the server's private filesystem at storage/app/private, accessible only to the queue worker user.
Backups: Daily encrypted backups (additional encryption layer beyond the column-level encryption above) are uploaded to Cloudflare R2.

4.3 Multi-tenant data isolation

GigDex is multi-tenant. Each agency owner's data is logically isolated from other agencies via tenant-scoped database queries. We have automated tests that verify a user cannot access data belonging to another agency. The isolation rules are documented internally and audited regularly.

4.4 Access by our team

Access to production data is restricted:

Only GigDex's named operator(s) (employees, contractors, or directors of Aloura Entertainment Ltd authorised for this role) have SSH access to production servers
Database access requires SSH tunnelling — there are no public database endpoints
Production credentials are not shared with third parties
We do not have a "support impersonate" feature that bypasses tenant isolation (admin impersonation is logged + restricted to your explicit consent for specific support cases)

5. Subprocessors (third parties who process your data on our behalf)

We use the following subprocessors strictly to provide the Service:

| Subprocessor | Purpose | Location | Data shared | |---|---|---|---| | Hetzner Cloud | Production server hosting | Germany (EU) | All application data | | Cloudflare R2 | Encrypted backup storage | Multi-region | Backup files (encrypted) | | Cloudflare | DNS + CDN + DDoS protection | Multi-region | Request metadata only | | Laravel Forge | Server management interface | Hosted in the US | Deployment metadata only — no business data | | Stripe | Subscription billing (your payment to us) + client-payments processing (if you enable Stripe checkout for your clients) | EU + US | Payment information (Stripe is PCI-DSS Level 1; we never see card numbers) | | Twilio | SMS sending (if you enable) | US (with EU data residency option) | SMS recipient phone + body | | Resend | Transactional email fallback (when Gmail is unavailable or not configured) | EU + US | Email recipient + body | | Google (Gmail, Drive) | Email sending + PDF backup (if you enable) | Multi-region | Per the scopes in §3.2 above | | Sentry | Error monitoring (optional — disabled by default; enabled per-environment via SENTRY_LARAVEL_DSN) | EU + US | Error stack traces; may incidentally include data subject IDs |

Note on encrypted backups containing OAuth tokens: the daily encrypted backups uploaded to Cloudflare R2 (see §4.1) include the encrypted database, which contains your Gmail/Drive OAuth refresh + access tokens (encrypted at the database-column level per §4.2 and additionally encrypted at the backup level). Backups are retained per the schedule in §6 and deleted when their retention window expires.

All subprocessors are bound by Data Processing Agreements (DPAs) that ensure GDPR-equivalent protections.

We do not sell your data, ever.

6. Data retention

We retain your data for as long as your account is active. Specifically:

| Data type | Retention | |---|---| | Account + business operational data | While your account is active; deleted on account closure (see §7) | | Google OAuth tokens | Until you click "Disconnect Gmail" or close your account | | Email content records (invoice emails etc.) | While your account is active; deleted on account closure | | Backups | Daily backups retained for 14 days (7 immediate + 7 archived); weekly backups retained for 4 weeks; monthly backups retained for 1 month. Backup data is deleted from Cloudflare R2 per the retention schedule (documented in docs/deployment-and-backups.md §Backup Retention Policy). | | Sentry error logs | 90 days (Sentry's standard retention) | | Authentication session logs | 30 days | | Financial/invoice records (subscription billing) | Retained for 7 years after your last invoice, as required by UK tax law (Companies Act / HMRC), even after account closure. Held separately from operational data. |

7. Your rights (UK GDPR + Data Protection Act 2018)

You have the following rights under UK GDPR. To exercise any of them, email [email protected]. We respond within 30 days.

| Right | What it means | |---|---| | Right to access | Request a copy of all personal data we hold about you. We provide a structured export (JSON or CSV). | | Right to rectification | Correct inaccurate personal data. Most account data is editable directly via the in-app Settings; we can correct anything else on request. | | Right to erasure ("right to be forgotten") | Request deletion of all your personal data. We delete within 30 days of confirming the request. Some data (financial records — see §6) may be retained where UK law requires. | | Right to restrict processing | Request that we pause processing your data while a dispute is resolved. | | Right to data portability | Receive your data in a machine-readable format (JSON) that you can take to another service. | | Right to object | Object to processing based on legitimate interests. | | Right to withdraw consent | Where any of our processing is based on your consent (UK GDPR Art. 6(1)(a) or Art. 9(2)(a)), you may withdraw that consent at any time. The lawful-basis table in §3.4 sets out which purposes (if any) rely on consent; at present, none of the core processing we carry out relies on Art. 6(1)(a) consent (the Google integration is now operated under the Contract basis as part of the paid Service). Disconnecting integrations or cancelling subscriptions is handled as outlined separately below — these actions disable optional features and end the contract respectively, but they are not "consent withdrawal" events in the UK GDPR sense. | | Disconnecting optional features (not a UK GDPR right per se, but listed here for clarity) | You can disconnect Gmail/Drive/Spotify/Twilio integrations at any time via in-app Settings. You can cancel your subscription via the Stripe customer portal accessible from in-app Settings. |

7.1 How to disconnect Google account access

To revoke GigDex's access to your Gmail and Drive:

In GigDex: Settings > Integrations > Disconnect Gmail
Independently, at Google: visit https://myaccount.google.com/permissions, find "GigDex", click "Remove access"

Once disconnected, we delete the stored OAuth tokens within seconds. Drive file IDs (references to files in your Drive) are retained in case you reconnect later — they are not personal data, just identifiers — but you can request their deletion at any time.

7.2 How to delete your account

To delete your entire GigDex account + all associated personal data:

Email [email protected] with the subject "Account Deletion Request"
We confirm by replying to your account email address
Within 30 days of confirmation, we delete: account record, business operational data, Google OAuth tokens, email/SMS content, generated PDFs
Backups containing your data are deleted on the retention schedule in §6 — daily backups within 14 days, weekly backups within 4 weeks, and any monthly backup within 1 month of account closure, after which no copy of your operational data remains in the backup system (subject only to financial records retained under §6 for UK tax-law compliance)

7.3 Complaints

If you believe we've handled your data improperly, contact us first at [email protected] so we can resolve it. If you remain unsatisfied, you have the right to lodge a complaint with the UK Information Commissioner's Office (ICO):

Website: https://ico.org.uk
Phone: 0303 123 1113

8. International data transfers

Some subprocessors (Stripe, Twilio, Sentry, Forge, Google) process data in the United States. We rely on:

The UK Government's adequacy decision for transfers to the EU (Hetzner, Resend)
Standard Contractual Clauses (SCCs) for transfers to the US
The UK-US Data Bridge / Data Privacy Framework where applicable

Where transfers are necessary, we ensure GDPR-equivalent protections via contract.

9. Children

GigDex is a B2B service and is not directed at children. We do not knowingly collect personal data from anyone under 18. If you become aware that a child has provided personal data to us, please contact [email protected] and we will delete it.

10. Changes to this policy

We may update this Privacy Policy from time to time. Material changes will be:

Notified by email to your registered account address
Published at https://gigdex.co.uk/privacy with an updated "Effective date" at the top

Continued use of the Service after the effective date constitutes acceptance of the updated policy.

11. Contact us

Data controller: Aloura Entertainment Ltd Trading as: GigDex Registered address: Unit 4 Hurricane Drive, Hurricane Business Park, Liverpool, Merseyside, L24 8RL, United Kingdom Companies House number: 16338729

Contact addresses (each routes to a dedicated inbox so messages reach the right person quickly):

| Topic | Email | |---|---| | Privacy, data protection, GDPR / DSARs, complaints, legal notices, DPA requests, court correspondence | [email protected] | | General customer support, account help, technical questions | [email protected] | | Security vulnerability disclosures | [email protected] |

Data Protection Lead: Benjamin Mark Paveley, Director of Aloura Entertainment Ltd — reachable at [email protected].