Get started
Authentication and scopes
Every call carries an API key. A key reaches one workspace, does what its scopes allow, and can expire.
Sending the key
Send the key as a Bearer token. Tools that can only fill a named header may use X-Api-Key instead; the two are the same key.
GET /api/v1/events HTTP/1.1
Host: attendbeacon.com
Authorization: Bearer abk_k7m2qx9vtw4p_...A key looks like abk_, twelve characters, an underscore and a secret of 43. The twelve characters are its prefix: the workspace shows them so you can tell keys apart, and the activity of keys names keys by them. Secret scanners recognise the abk_ marker, so a key pushed to a repository by mistake is easy to find.
Only HTTPS is answered. There are no cookies and no sessions: every request stands alone.
What a key reaches
A key belongs to one workspace and reaches nothing else. An event, an attendee or a webhook of another workspace answers 404, exactly as if it did not exist, so a key can never learn what another organiser has.
The demonstration workspace has no keys of its own. Make a workspace of your own to try writes; reads of Beacon Summit in these docs are the demonstration's real data.
Scopes
A scope is an area and an access: events:read, attendees:write. Give a key the scopes its software needs and nothing more, so a key that leaks gives away no more than that.
- Write holds read in the same area: a key with
program:writecan read sessions too. people:readis its own scope. Without it, people are ids: an attendee has a ticket, a status and a check-in time, but no name, address, company or answers, andpersonalDatasayswithheld. Counts, sales and the programme need no person.- A call that needs a scope the key lacks answers
403with"code": "missingScope"and"scope"naming what is missing. Scopes are chosen when a key is made; for different scopes, make a new key.
| Scope | Allows |
|---|---|
events:read | Events: the list, details, statistics, registration questions and doors. |
events:write | Create draft events, change their basics and publish or unpublish them. |
tickets:read | Ticket types, add-ons and discount codes, with what is sold. |
tickets:write | Change a ticket type's capacity and sales window, and create discount codes. |
orders:read | Orders and their money, and the sales pace. |
attendees:read | Registrations and attendees: ticket, status and check-in; names and answers need people:read too. |
attendees:write | Register people with a free ticket and cancel tickets, as the workspace does. |
checkins:read | Door scans and check-in counts. |
checkins:write | Check attendees in at a door, by the scanner's rules. |
program:read | Sessions, rooms, tracks and speakers. |
program:write | Add and change sessions on the agenda. |
sponsors:read | Sponsors, exhibitors, their levels and consented leads. |
cfp:read | Call-for-speakers submissions and their status. |
crew:read | Crew, volunteers, roles and shifts. |
surveys:read | Surveys, session ratings and their results, never who answered. |
finance:read | Invoices, credit notes and the budget summary. |
sharekit:read | The share kit's leaderboard of speakers, sponsors and attendees who spread the word. |
communities:read | Communities and their members. |
webhooks:read | Webhook endpoints, their deliveries, the event types and subscriptions for automation platforms. |
webhooks:write | Add, change, test and remove webhook endpoints. |
people:read | Personal data in any of the above: names, email addresses, companies and answers. Without it, people are ids only. |
The workspace offers four starting points: Dashboard (events, tickets, orders, check-ins and the programme, read only), Power Automate or Zapier (what the connector and the Zapier app use), AI assistant (everything to read, people included) and Everything.
Keys made before October 2026
Keys from before scopes per area had read and write. They were rewritten to what those meant, and keep working exactly as before: read became every read there was (people included), write became attendees:write and checkins:write. Nothing gained a new power.
Expiry and revoking
A key may expire after 30, 90, 180 or 365 days, or never. An expired key answers 401 with "code": "keyExpired"; make the new key before the old one's day and swap it in, and nothing stops.
Revoking a key in the workspace stops it at once (keyRevoked). The Power Automate flows and Zaps it subscribed are unsubscribed with it, because they could no longer unsubscribe themselves.
The activity of keys
Integrations › API & MCP › Activity of keys lists every call a key made through the API or the MCP server in the last 90 days: when, which operation (the route, such as GET /events/{eventId}/attendees, or the MCP tool), how it was answered, how long it took and from which address. Never a query string, a body or an answer: an attendee's address in a search must not sit in a log. Refused calls are there too, with their code, so missingScope or rateLimited is the first place to look when a flow stops.
Changes made with a key also appear in the workspace's activity log, named after the key: "API key abk_k7m2qx9vtw4p (Attendee sync for the CRM)".
Keeping keys safe
- One key per piece of software, named after it, so you can revoke one without stopping the others.
- Keep keys in a secret store (Key Vault, your CI's secrets, a password manager), never in code or a repository.
- Never send a key to a browser. The Try it button in these docs is the exception you make yourself: the key stays in that page's memory and goes only to attendbeacon.com.
- Give keys an expiry, and revoke the ones the activity list shows nobody uses.