API access for custom integrations

API access is part of the Peak plan. It lets a system you control — a council dashboard, a spreadsheet sync, a website — read your unit’s data without anyone signing in.

What it can read

Endpoint	Returns
GET /api/v1/integration/roster	Your unit’s members, paged
GET /api/v1/integration/events	Upcoming events
GET /api/v1/integration/members/{memberId}/advancement	One Scout’s advancement

It is read-only. Nothing in this API changes your data. Roster edits, advancement sign-offs and event changes all carry youth-safety and consent steps that assume a person is present, so they stay in the app rather than being exposed to a script.

The roster respects the same privacy rules as the app: youth BSA member IDs are masked, and nothing you cannot see in the member directory appears here.

Creating a key

There is no key-management screen in the app yet. Keys are managed through the settings API, signed in as a person with the manage settings permission (a key cannot manage keys), and only while your unit is on Peak.

1. Send POST /api/v1/settings/api-keys with a name describing what will use the key — “Council roster sync” is more useful in six months than “key 1” — and, optionally, an expiresAt date.
2. Copy the key from the response immediately. It is shown once and never again.

GET /api/v1/settings/api-keys lists your unit’s keys without their secrets.

Using a key

Send it as a bearer token:

curl https://api.mysummitkeep.com/api/v1/integration/roster \
  -H "Authorization: Bearer msk_live_YOUR_KEY_HERE"

The key identifies your unit, so there is no unit ID to pass — a key can only ever read the unit it was created for.

If a key leaks

Revoke it with DELETE /api/v1/settings/api-keys/{keyId}. Revocation takes effect immediately and cannot be undone; create a replacement rather than trying to restore the old one.

Two things make a leak easier to survive:

• We never store your key, only a one-way hash of it. Nobody at MySummitKeep can read it back to you, and a database copy contains no usable credentials.
• The key list includes a last used time for each key. A key nothing has used is a key you can revoke without worrying about what breaks.

An API key cannot create or list other API keys. If one is stolen, the thief cannot mint a second key to survive your revoking the first.

Rate limits

Requests are rate limited. Exceeding the limit returns 429 Too Many Requests; back off and retry later rather than retrying immediately, which only re-trips the limit.

Keeping a key safe

• Store it the way you would a password: a secrets manager or an environment variable, never in a spreadsheet, an email, or committed to a repository.
• Use a separate key per integration, so revoking one does not break the others.
• Set an expiry on keys for anything short-lived.