API Authentication & Security

BrightStar's API authenticates every request with an API key rather than a username-and-password login or a session cookie. That single decision shapes how you build against it: whether you're wiring a retreat's registration form into BrightStar, pulling attendee counts into a reporting dashboard, or connecting a check-in tablet at a kirtan door, the key you use is the identity the API sees for that connection. This guide covers the key types BrightStar issues, how authentication actually works on the wire, what the rate limits mean in practice, and what to do if a key ends up somewhere it shouldn't.

BrightStar issues three kinds of keys, and the difference between them is really a difference in blast radius if one leaks. A live key, prefixed bs_live_, has full read and write access and is meant for production — the application actually selling tickets or managing your event data. A test key, prefixed bs_test_, has the same full read/write permissions but only against sandbox data, so you can build and break things during development without touching a real event or a real attendee record. A read-only key, prefixed bs_read_, can't write anything at all, which is exactly what you want behind a reporting tool or an analytics dashboard that only needs to look at numbers — if that key ever leaks, there is nothing it can change. Choosing the narrowest key that does the job for a given integration is the simplest security decision available on this API, and it costs you nothing in day-to-day use.

Every request carries its key as a bearer token: an Authorization header reading Bearer followed by the key itself, sent alongside a Content-Type of application/json to BrightStar's API base URL. A standard curl call or any ordinary HTTP client handles this without an SDK. In practice the endpoint is forgiving about exactly where the key shows up — the Authorization header, an X-API-KEY header, or an api_key query parameter, which is how tools like Zapier send it by default — and a stray repeated Bearer prefix gets stripped rather than causing the request to fail outright. Once BrightStar verifies the key, it resolves to the organizer account that owns it, and everything the request returns is scoped to that account's own data. That scoping is the real protection underneath all of this: a key can only ever act as the account it belongs to, and never reach across into someone else's events, registrations, or attendees.

BrightStar limits each API key to 100 requests per minute and 1,000 per hour, with a burst allowance of 20 requests per second for short spikes. Every response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, so you can see exactly how much room is left and when the window resets, rather than discovering the limit only after you've hit it. Limits are tracked per key and per endpoint, not across your whole account, and the allowance is generous relative to ordinary use — an integration polling every few minutes for updated registrations will never come close. Go over it and you'll get a 429 response carrying a Retry-After header telling you how many seconds to wait before trying again. Waiting that out, rather than retrying immediately, is the correct response and the fastest way back to normal service.

If you suspect a key has leaked — pushed to a public repo, exposed in a log, shared with the wrong person — treat it as compromised immediately rather than waiting for evidence of misuse. Go to Settings, then API Keys, then Revoke, and cut the key off. Generate a new key and update every application that was using the old one; other keys on your account keep working, so revoking one doesn't force you to rotate everything at once. BrightStar notes that compromised keys may lead to account suspension, which is one more reason to act the moment you suspect exposure rather than after you've confirmed damage.