In development. This is on the roadmap and not available yet. The guide is here so it is ready the day it ships.
Integrations & API

Zapier Integration — Send Buyers Anywhere

Connect BrightStar to your CRM, email tool, or spreadsheet. Every ticket buyer flows out automatically, with no export step.

4 min readUpdated 2026-07-29

Your buyer list is worth more when it reaches the tools you already work in. Most of what you know about who is coming to your kirtan, your weekend retreat, or your sound healing evening lives in two places: BrightStar's order records, and whatever email tool or spreadsheet you actually check every day. The gap between those two is usually a manual export you mean to do and don't get to. Zapier closes that gap. The integration sends each purchase to wherever you keep your people — Mailchimp, HubSpot, Google Sheets, Airtable, or any of the thousands of apps Zapier speaks to — the moment it happens, so the record in your CRM is never a week behind the record BrightStar already has.

Connecting

One-time setup, about two minutes. You do this once per Zap, not once per event — after it's connected, every future purchase for events you've opted into syncing flows through on its own:

  1. 1Open Dashboard → Integrations and generate a Zapier API key
  2. 2In Zapier, create a Zap and choose BrightStar as the trigger app
  3. 3Paste your key when prompted — Zapier verifies it immediately
  4. 4Pick a trigger: New Ticket Buyer, New Attendee, or Refund Issued
  5. 5Choose your destination app and map the fields you care about

What travels with each buyer

Every synced record carries the basics you'd expect: name, email, and order reference; the event's title, date, and venue; the ticket type, quantity, and amount paid; and the timestamp of purchase. When you collect them, phone number and answers to your custom attendee questions travel too — and they arrive using your own question wording, not an internal field id, so a teammate looking at the record in Mailchimp or a spreadsheet sees the actual question you asked, not a code that means nothing outside BrightStar.

Ticket lines are grouped by type, so a buyer who bought two general admission and one VIP shows up as separate line items rather than one flattened total, and tickets that were cancelled, refunded, or voided are left out of that count. Amounts arrive in whole currency units, and a coupon code used on the order travels along with the discount it carried, so what lands in your CRM reflects what the buyer actually paid.

Per-event control

Syncing is opt-in, per event, using the CRM Sync toggle on that event's Marketing tab. A private ceremony, a small closed retreat, or anything you don't want mixed into a general marketing list can stay off, while every other event on your account flows through normally. The toggle takes effect on the next purchase — turning it on doesn't reach back and push buyers who bought before you flipped it, and turning it off doesn't pull anyone back out of your CRM after the fact. What syncs is only what happens from that point forward.

There's a second gate alongside the toggle: consent. A buyer who has unsubscribed or been suppressed doesn't appear in the buyer or attendee feeds at all, and everyone who does come through carries their marketing-consent flag and the date it was given, so the tool receiving them can decide for itself whether it's allowed to reach out. Refunds are the one exception — a Refund Issued record still fires regardless of consent, because a refund is a fact about an order, not a marketing touchpoint.

What happens when something goes wrong

Three things tend to worry organizers once buyers are flowing automatically, and the honest answer to each is that BrightStar's own records stay intact no matter what happens downstream.

If a Zap fails, Zapier retries it on its own schedule — the buyer, ticket, and order are already recorded on BrightStar's side, so nothing about the purchase itself is at risk while a retry sorts itself out. If a key is revoked, every Zap using it stops immediately and Zapier shows an auth error rather than silently going quiet; generating a new key and reconnecting closes the gap with no data lost in between. And if a refund is issued, the Refund Issued trigger fires so your CRM can mark that contact accordingly — but the original purchase record isn't deleted automatically on your end. That's deliberate: what a refund should mean in your CRM is a decision about your list, not one BrightStar makes for you.

Choosing what to sync

Most organizers send buyers to one place and stop there, and that's usually the right instinct. If you're deciding where, the more useful question isn't which tool has the most features — it's which list you actually open. A CRM nobody logs into is worse than a spreadsheet you check every week, because a contact that arrives somewhere you never look is functionally the same as a contact that never arrived. Start with the destination you already work in day to day, confirm the first few purchases land correctly and with the fields you expect, and only add a second or third Zap once you trust the first one.

Your API key is shown once, at creation, and stored hashed after that — there is no screen where you can go back and reveal it again. If you lose it, don't treat that as an emergency: revoke it and generate a new one. Revoking takes effect immediately, and it only touches Zaps built on that specific key, so reconnecting doesn't disturb any other Zap you've already got running.

Common questions

Does BrightStar have a Zapier integration?

Yes. BrightStar connects to Zapier so ticket buyers, attendees, and refunds flow automatically into any of the thousands of apps Zapier supports — including Mailchimp, HubSpot, Google Sheets, and Airtable. You generate an API key in Dashboard, Integrations and paste it into Zapier when creating a Zap.

Read more

Authentication is a single key rather than a linked account. BrightStar mints one beginning with bsk_, backed by 32 random bytes, and stores only its SHA-256 hash, so the usable string exists in Zapier and nowhere else. Each request presents it — as a bearer token, an X-API-KEY header, or Zapier's api_key query parameter — and the hash lookup resolves it to your organizer account, which is what confines every trigger to your own events. Records served are logged, so the dashboard can show a real count of buyers synced rather than an estimate.

What triggers are available?

Three: New Ticket Buyer fires on each completed purchase, New Attendee fires per admitted person including additional guests on a multi-ticket order, and Refund Issued fires when a refund completes.

Read more

All three are polling triggers rather than webhooks: Zapier asks for new records on its own schedule and BrightStar returns up to 100 at a time, 200 at most. With no cursor the newest come first; with a since cursor it returns the oldest records after that point, ordering on the timestamp and then on the record id, so two rows created in the same second cannot be skipped or served twice. Each record carries a stable id — the order, the registrant, or the order plus refund date — and that is what Zapier deduplicates on.

What buyer information does BrightStar send to Zapier?

Name, email, order reference, event title, date and venue, ticket type, quantity, amount paid, and purchase timestamp. Phone number and answers to your custom attendee questions are included when you collect them, using your own question wording rather than internal field ids.

Read more

Name, phone, and address are read from the registrant record for that event first, with the address captured at checkout as a fallback, since the registrant row is the more reliable identity. Ticket lines are grouped by ticket type with a quantity and a price each, and tickets that were cancelled, refunded, or voided are left out of that count. Amounts arrive in whole currency units rather than cents, and a coupon code used on the order travels with the discount amount it carried.

Can I sync some events but not others?

Yes. Syncing is opt-in per event via the CRM Sync toggle on each event's Marketing tab, so a private or sensitive gathering can stay out of your CRM while everything else flows through.

Read more

The toggle is one of two gates. The other is consent: a buyer who has unsubscribed or been suppressed is dropped from the buyer and attendee feeds entirely, and everyone who does travel carries their marketing-consent flag and the timestamp it was given, so the receiving tool can make its own decision about contacting them. Refunds are deliberately exempt from that filter, since a refund is a transactional fact about an order you need to know about regardless of anyone's marketing preferences.

If I turn off CRM Sync for an event, does it remove buyers who already synced?

No. The toggle only affects purchases going forward. Buyers who synced before you turned it off stay in your CRM, and turning it back on later doesn't reach back to push in anyone who bought while it was off.

Read more

Think of the toggle as controlling a tap rather than a hose — it decides what flows from now on, not what's already sitting downstream. That means switching an event off mid-sale won't undo the records you already have, and switching it on won't backfill the buyers you missed while it was off. If you need those earlier buyers in your CRM, you'd need to account for them separately.

Does a refund automatically remove the buyer from my CRM?

No. The Refund Issued trigger fires so your CRM knows a refund happened, but BrightStar does not automatically delete the original purchase record on your end.

Read more

That's a deliberate boundary rather than a gap: what a refund should mean in your CRM — deleting the contact, tagging them, leaving the record as-is for your own reporting — depends on how you run your list, and BrightStar doesn't assume an answer on your behalf. The trigger simply hands you the fact of the refund; the follow-up action inside your CRM is yours to define.

What happens if I lose my API key?

Keys are shown once at creation and stored hashed, so they cannot be retrieved later. Revoke the lost key and generate a new one — revoking is immediate and does not disturb your other Zaps.

Read more

This is by design rather than an oversight: BrightStar stores only a hash of the key, so there is nothing to reveal even if you ask for it back. Losing a key isn't a data emergency, since the buyer, ticket, and order records that matter are already saved on BrightStar's side regardless of what happens to any given key. Revoking one key only stops the Zaps built on it — everything else on your account keeps running untouched.

Ready to get started?

Create your first event on EveryEvent Bangkok — it’s free.