Security and Data Residency
Where TixBloom keeps your data, who can reach it, the controls organisers get and the service providers we rely on.
Version 2.0 · Effective 16 October 2026 · TixBloom
1. Data residency
1.1 TixBloom is hosted in the Singapore region. The primary database, database backups, file uploads and email logs are stored in Singapore. We do not replicate stored data to another region for storage.
1.2 Some data transits or is processed by service providers outside Singapore in the course of delivering the service, for example when an email is handed to the delivery provider, when a page is served through a content delivery network, when an error report is captured, or when an AI feature calls a model provider. Transfers are covered by contractual protections as described in the Privacy Policy.
1.3 Payment card data never touches TixBloom. Cards are entered on the payment provider's hosted page or fields and TixBloom stores only the provider's reference, amount and status.
1.4 Organisers who connect their own tools (Slack, CRM or spreadsheet integrations, webhooks, the API, the MCP server) decide where that copy of the data goes. TixBloom documents what each integration sends.
2. Isolation between organisations
2.1 Every database table that holds organiser, exhibitor or attendee data carries row-level security. The application connects as a restricted database role and each query runs in the context of the signed-in person, so an organiser, an exhibitor, an API key or a webhook can only reach rows that belong to its own organisation. Sensitive columns can be changed only by platform code.
2.2 Secrets that organisers give us (payment provider keys, Slack URLs, identity provider client secrets, PayPal credentials) are encrypted at rest with a key the application role cannot read back in plain text.
2.3 Demo data is flagged and excluded from production analytics and billing, and demo workspaces cannot reach real payment providers or send email to real addresses.
3. Access and authentication
3.1 Sign-in uses single-use email links and codes that expire after 20 minutes, or single sign-on through the organisation's OpenID Connect provider on plans that include it. Organisations can require SSO for verified email domains. Platform administrators use passwords with rate-limited sign-in and a separate console.
3.2 Workspace roles (owner, admin, finance, marketing, check-in) and event-level staff assignments limit what each person sees and does. Owners can revoke access at any time. Every significant action is written to an audit log that organisers can review and export.
3.3 Platform staff access customer workspaces only for support, security or legal reasons, through an impersonation facility that records who, why and for how long, and that is visible in the audit log.
4. Operations
4.1 Backups are taken daily with point-in-time recovery; restores are tested as part of release checks. Dependencies are kept current and security advisories are triaged within one business day.
4.2 API traffic is rate-limited per key and per plan; sign-in, export and public endpoints are rate-limited per person and network. Webhook deliveries are signed so receivers can verify them. A web application firewall and a virtual waiting room protect on-sales from floods.
4.3 Changes go through automated tests and a production build before deployment, and are deployed with the ability to roll back.
5. Service providers (sub-processors)
5.1 Application hosting and content delivery: Vercel. Database: a managed PostgreSQL service in Singapore. Transactional email: Resend. Payments: the provider each organiser connects (Stripe, HitPay, PayPal, 2C2P, Adyen, NETS or Braintree) and, for TixBloom invoices, Stripe and PayPal. Domains and TLS: Vercel. AI features: a model provider bound not to train on customer data. A current list with locations is available on request; organisers on a plan with a Data Processing Addendum are told at least 30 days before a new sub-processor is added and may object.
6. Incidents and reporting a concern
6.1 We notify affected organisers of a confirmed personal data breach without undue delay and in any case within 48 hours of confirming it, with the information they need to meet their own notification duties. Where the PDPA requires, we notify the Personal Data Protection Commission and affected individuals.
6.2 Security reports: billing@tixbloom.com. We acknowledge within two business days and keep reporters informed until the issue is resolved. Good-faith research under the Acceptable Use Policy is welcome.
6.3 This statement describes our current practices and is updated as they change. It is not a warranty or service level; those are only as stated in the Terms of Service or a written agreement.