Developers

Brief the model before it writes code.

One prompt covering everything on this page that a generated integration usually gets wrong: which endpoints are public, which key must never leave your server, and that RSVP and attendance belong to the canonical flow. Paste it first, then describe what you want built.

Hand this to an LLM: what to read, what stays server-side, what it must never do.

Read the prompt

You are helping integrate BoilerLoop (https://boilerloop.com) into our club's website. Club slug: {slug}. BoilerLoop is the source of truth for events, registrations and attendance. Follow these rules exactly.

READ (public, no credentials):
- GET https://boilerloop.com/api/v1/events/{eventId} — one event as display-safe JSON (title, description, timing + timezone, location, hosts, tags, cover image, capacity, going count, availability, status, visibility, walk-in policy, public registration questions, url, calendar links).
- GET https://boilerloop.com/api/v1/events/{eventId}/calendar[?series=true] — ICS.
- GET https://boilerloop.com/api/v1/organizations/{slug}/events?scope=upcoming&page=1&limit=10 — the club's public events.
- GET https://boilerloop.com/api/v1/organizations/{slug}/calendar — subscribe to the club's public calendar feed.
- These return public events only, regardless of cookies; restricted events are 404 here. Responses support ETag / If-None-Match. Read-only CORS is open, so this is the surface to call from a browser.
- If the JSON includes an `image` object, render `image.url` (resolve it against https://boilerloop.com) with its `width`/`height` and object-fit: cover; fall back to your own placeholder if it fails to load.

MANAGE (server-to-server only):
- https://boilerloop.com/api/v1/manage/... accepts a club-scoped bearer key minted in Workspace → Integrations: `Authorization: Bearer be_live_…`. Scopes: events:read, events:write, registrations:write, attendees:read, attendees:sensitive.
- Call it only from our own server-side code (API route, backend job, serverless function) using a key read from a server environment variable. There is no CORS on these routes.
- With registrations:write, POST https://boilerloop.com/api/v1/manage/events/{eventId}/registrations with {email,name,answers}. DELETE the returned registration at https://boilerloop.com/api/v1/manage/events/{eventId}/registrations/{registrationId}. The key must belong to the primary host. Duplicate active email+event submissions return the existing registration; capacity and waitlist are enforced server-side.
- Never put a management key in browser JavaScript, HTML, a client bundle, a query string, a repository, or in anything you output to me as code I might commit. Never invent a key value. If a key is needed and absent, stop and tell me to mint one.

REGISTRATION, CHECK-IN AND ATTENDANCE:
- A club site with a server can collect attendee registration fields and submit them through its server-side key. BoilerLoop matches the normalized email to a verified account now or when that email is later verified. A club-submitted email does not itself verify identity. A site without a server should link to https://boilerloop.com/events/{event-slug} for RSVP.
- Keep first-party rotating-QR check-in at https://boilerloop.com/checkin/{eventId} for attendance.
- Or use the official embed: `<script src="https://boilerloop.com/embed.js" defer></script>` then `<boiler-event event-id="{eventId}" mode="card"></boiler-event>` (modes: card, detail, rsvp, calendar, list). Theme it with --be-accent, --be-radius, --be-font. The embed renders public API data and links out.
- Never send a management key or registration write directly from browser code. Never write attendance from the club site: check-in requires the live QR flow.
- There are no webhooks or attendance-write API in BoilerLoop today. Do not invent one. If our site needs a signal, poll the read API.
- Handle attendee emails and answers only as needed to submit registrations; do not publish them on our site.

OUTPUT:
- Preserve our existing layout, typography, spacing, responsive behavior and keyboard accessibility; escape all text you render.
- Respect each event's `visibility` and `status`; keep the BoilerLoop attribution and a link to the canonical event page.
- Full documentation: https://boilerloop.com/developers.

Public read API

GET https://boilerloop.com/api/v1/events/{id-or-slug}
GET https://boilerloop.com/api/v1/events/{id}/calendar?series=true
GET https://boilerloop.com/api/v1/organizations/acm/events?scope=upcoming&page=1&limit=10
GET https://boilerloop.com/api/v1/organizations/acm/calendar

Returns: Canonical id, slug, hosts (primary/co-host), timing, timezone, series and override, location, tags, capacity, going count, availability, visibility, walk-in policy, public registration questions, calendar links, and image (url, width, height) when the club uploaded a cover — resolve the URL against the origin; it is null otherwise.
Never returns: Restricted events (Purdue-only, invite-only, members-only are 404 here regardless of cookies), attendee identities, answers, invite lists, rosters, credentials, storage locations of uploaded images.
Caching: ETag / If-None-Match → 304. max-age 60, stale-while-revalidate 300. Wildcard read-only CORS.
Errors: {"error":{"code":"NOT_FOUND","message":"Public event not found."}} · 400 INVALID_QUERY · 405 for writes.
Versioning: v1 changes are additive. Anonymous rate limiting is applied at the deployment edge, not by this app.

Management API

Authorization: Bearer be_live_…   # created by a club owner in Workspace → Integrations

GET    https://boilerloop.com/api/v1/manage/events                    scope events:read   (includes restricted events)
POST   https://boilerloop.com/api/v1/manage/events                    scope events:write
GET    https://boilerloop.com/api/v1/manage/events/{id}               scope events:read
PATCH  https://boilerloop.com/api/v1/manage/events/{id}               scope events:write
POST   https://boilerloop.com/api/v1/manage/events/{id}/registrations scope registrations:write (email, name, answers)
DELETE https://boilerloop.com/api/v1/manage/events/{id}/registrations/{registrationId} scope registrations:write
GET    https://boilerloop.com/api/v1/manage/events/{id}/attendees     scope attendees:read (+ attendees:sensitive for sensitive answers)

Scope: A key belongs to one organization. Event and registration writes work on events the club primarily hosts; attendee reads require primary hosting or an explicit co-host grant. Registration writes are idempotent by event and normalized email, and use the same capacity, waitlist, and question validation as first-party registration.
Limits: 120 requests/minute per key with X-RateLimit-Limit/Remaining/Reset; 429 includes Retry-After. Every call is written to the club audit log with key id, method, path and status.
Not available: No endpoint creates attendance. A club key with registrations:write can submit or cancel registrations for its own events. A submitted email is matched to a verified BoilerLoop person now or after verification; the submission does not verify that email. Attendance only comes from the first-party check-in flow below. Keys are hashed at rest, shown once, revocable, and must stay on a server — there is no CORS on these routes.

First-party check-in

Every event has a rotating check-in code (30–60 s). Staff open /checkin/{eventId}/display; attendees scan it, land on /checkin/{eventId}?t=…, verify their email (a session cookie), answer required check-in questions, and the browser posts to POST /api/events/{eventId}/checkin with a signed scan ticket.

The server validates the event, the token or ticket (HMAC with a per-event secret, current or previous window, ticket lifetime 10 minutes), the check-in window, the viewer’s visibility/eligibility (Purdue verification for Purdue-only events), the RSVP or walk-in policy, and the required answers. Duplicates return the original record. A QR scan proves someone saw a live code recently — codes can be shared, and no GPS or Bluetooth is used.

Official embed

<script src="https://boilerloop.com/embed.js" defer></script>
<boiler-event event-id="evt-…" mode="card"
  style="--be-accent:#c79a6b;--be-radius:16px">
</boiler-event>

Modes: card, detail, rsvp, calendar, list (organization="acm"). Theme tokens: --be-accent, --be-radius, --be-font. The embed renders public API data in a Shadow DOM and links RSVP/check-in to the canonical event page. To collect registrations on your own site, send them from your server with a scoped club key. The embed emits a browser-local boilerloop:lifecycle DOM event for your own analytics; nothing an embed does counts as RSVP or attendance.

Fetch in your own design

const res = await fetch('https://boilerloop.com/api/v1/events/evt-…');
if (!res.ok) throw new Error('Event unavailable');
const { data } = await res.json();
// Render text safely; resolve relative links against the origin.
// Link to data.url for RSVP; never rebuild registration client-side.

Trust is not a theme token.

Browser clients cannot hold a club key. Club server integrations can submit registrations for the primary host, while participant actions on BoilerLoop require the participant’s verified session. Check-in still requires a live QR token. Management keys can never fabricate presence. Attendee data is organization-scoped; co-hosts need an explicit grant; sensitive answers need the sensitive scope or an owner session.