Webhooks

When someone buys a ticket to your kirtan evening, checks in at the door of your weekend retreat, or transfers a ticket to a friend, that action happens instantly inside BrightStar. A webhook is how your own tools find out about it just as fast, without you having to log in and check. Instead of polling BrightStar's dashboard every few minutes to see if a new order came in, BrightStar sends a message directly to a URL you control the moment the event happens. You configure that endpoint once, and BrightStar handles delivering real-time updates on orders, check-ins, and more to it going forward. This matters most for organizers running check-in tools, attendee databases, or automated follow-up flows around retreats, festivals, and ceremony gatherings — anywhere you need your own systems to stay in sync with what's actually happening at the door.

BrightStar groups webhook events around the three things that actually change during a gathering: orders, tickets, and the event listing itself.

Order events cover order.created, order.refunded, and order.cancelled — the moments someone buys in, gets money back, or backs out entirely. If you're syncing a spreadsheet of paid attendees for a retreat, order.created is the one you'll lean on most.

Ticket events cover ticket.checked_in and ticket.transferred. ticket.checked_in fires the instant a ticket is scanned at your kirtan door or festival gate, useful if you're feeding a live headcount into another system. ticket.transferred fires when someone sends their ticket to a new owner, which matters if your check-in tool needs the current attendee's name rather than whoever originally bought the ticket.

Event events — event.published, event.updated, event.cancelled — track the listing itself, useful if you mirror your event details onto your own site or app.

Every webhook BrightStar sends is a POST request with the same basic shape: an id for that specific delivery, a type telling you which event it is (order.created, ticket.checked_in, and so on), a created_at timestamp, and a data object holding the actual resource.

For an order event, that data includes the order's own id, the event_id it belongs to, the total and currency charged, and an array of tickets — each with its own id, ticket type, attendee name, and attendee email. That's enough detail to build an attendee list, print a badge, or reconcile a payment without a second call back to BrightStar. Because the same shape applies across every event type, you can write one parser and branch on type rather than treating each event as a special case.

BrightStar gives your endpoint 30 seconds to respond and expects an HTTP 2xx status back. If your server is down, times out, or returns an error, BrightStar doesn't give up immediately — it retries, spacing the attempts out: 1 minute, then 5 minutes, then 30 minutes, then 2 hours, then 24 hours after the failure. That widening gap gives you room to notice and fix a broken endpoint without your inbox getting flooded with repeated attempts. If all five retries fail, BrightStar disables the webhook rather than continuing indefinitely. Once you've fixed whatever was wrong with your endpoint, you re-enable the webhook yourself under Settings → Webhooks — BrightStar won't silently start retrying an endpoint it has already given up on.