An internal operations view often needs status and context, not the ability to change records. Begin with the questions the screen answers, then choose the smallest set of read scopes and endpoints that support them. A convenient management key is not a substitute for defining the application’s role.
Map questions to resources
Use the published contract to choose the read path:
| Screen question | Candidate resource |
|---|---|
| Which forms are published? | Templates with active-version state |
| What is the event’s current completion picture? | Event retrieval and declared counts |
| Who arrived on the operating day? | Check-in list with organization-day context |
| Which record matches this participant? | Bounded participant or waiver search |
Each resource returns different information. Do not fetch full waiver details for every row if the screen only needs a limited operational list.
Keep the key on the server
Use the applicable scopes such as templates:read, events:read, checkins:read, participants:read or waivers:read for the resources actually needed. Keep the key in server-side secret storage and apply your own user authorization before returning data to the browser.
The scope guide lists the contract boundaries. Some management resources do not offer a separate read-only scope, so do not invent one or call a broader endpoint simply because the HTTP method is GET.
Make freshness visible
Decide whether the view refreshes on demand, on a bounded interval or from a combination of reads and verified events. Show the last successful refresh separately from the current local clock. A failed refresh should not silently leave stale data looking current.
Use pagination only on endpoints that declare it, preserve filters while traversing pages and apply the documented rate limits. Avoid polling every participant record on every keystroke. For search, debounce input and handle empty-query behavior according to the specific route.
Keep observations separate from decisions
A signed record does not prove arrival, and a check-in does not settle every activity requirement. Label the facts your screen actually reads. Do not turn a read-only overview into an implicit approval system through vague wording such as “all cleared.”
Test an empty result, stale data, a permission error and a date boundary. Confirm the browser never receives the API key and ordinary logs do not capture participant payloads. Pair the design with organization-day reconciliation and record-access guidance.