CRM Integrations

When someone buys a ticket to your kirtan evening, signs up for a weekend retreat, or registers for a sound healing circle, that transaction holds more than a seat number — it's the start of a relationship you'll want to keep after the gathering ends. BrightStar lets you sync attendee data with your CRM so you can build your email list, track how people move from first ticket to repeat guest, and automate the follow-ups that keep a community coming back. Once the connection is set, that work happens in the background instead of you copying names into a spreadsheet after every event.

BrightStar has native integrations with three CRMs, each built around what that platform is set up to do. Mailchimp receives attendees as members of your Audience list, carrying name, email, the event attended, and ticket type — enough to build a mailing list and segment by which gathering someone came from. HubSpot receives the full attendee profile plus any custom properties you've defined, syncing to Contacts, since HubSpot is usually the system tracking a longer customer journey rather than just an email list. Salesforce syncs to Leads or Contacts using a field mapping you configure yourself, which fits how differently organizations use Salesforce compared to a marketing tool. Mailchimp and HubSpot sync immediately when a purchase happens; HubSpot also fires on lifecycle events. Salesforce can run immediate or batched, whichever suits how your team wants to receive the data.

The exact shape of what syncs depends on the platform, but a full attendee record — the kind HubSpot receives with your custom properties — carries a lot more than a name. It includes the order reference and purchase time, the buyer's email, first and last name, phone number, and an address broken into street, city, state, postal code, and country. Alongside that travels the event itself — its date and public listing URL — along with the order status, total, currency, and any discount code and amount that was applied, plus a line for each ticket type showing quantity and price. If your event asked attendees questions at checkout, their answers come through too, keyed by the question's own wording. Amounts arrive in ordinary dollars-and-cents form rather than the smallest currency unit, and every record carries a marketing consent flag along with the time that consent was given, so your CRM knows not just whether someone opted in but when.

Mailchimp, HubSpot, and Salesforce cover a lot of ground, but not every CRM an organizer of kirtan nights, retreats, or festivals relies on. For anything else, BrightStar exposes an order.created webhook: you set up an endpoint in your CRM, configure that webhook in BrightStar, map the payload fields to your CRM's fields, and process the incoming attendees through the API — the Webhooks documentation covers the exact payload shape. Alongside the webhook, BrightStar keeps three read endpoints, one each for ticket buyers, attendees, and refunds, returning JSON and authenticated with the same key you use elsewhere. Each accepts a timestamp so you only ask for what's new since your last check, and results come back in order and are deduplicated by their own id, so polling an overlapping window twice doesn't create duplicate contacts. That combination means any tool that can make an authenticated request — not just ones BrightStar has built a native connection for — can keep itself current on its own schedule.

Attendee data you sync to a CRM is subject to your own privacy policy, not BrightStar's, so the consent you need for email marketing is yours to secure before the data leaves BrightStar. BrightStar does not share attendee data with third parties unless you've explicitly configured an integration — nothing syncs by accident. Before a sync runs, anyone who has unsubscribed or been suppressed is dropped and never appears in the outgoing records. Everyone else carries their marketing consent state and the time it was recorded, so your CRM can apply its own consent rules rather than assuming permission exists. Refunds are treated differently: because a reversed purchase is a transactional fact rather than a marketing signal, refund records aren't filtered by consent, on the reasoning that you need to know about every refund on your own events regardless of whether that person opted into marketing.