Skip to main content
Each entry names the version of the OpenAPI file (info.version) that it describes.
​
November 2026
The Scoutworks MCP server, at https://mcp.scoutworks.app/mcp. Claude Code, Claude Desktop, Cursor, VS Code and other MCP clients can now read your group’s data with an API key. See Connect an AI assistant to your data.
  • One tool for each read endpoint, with the same parameters and the same JSON. A new read endpoint becomes a tool too.
  • The assistant sees only the tools that the key’s scopes open. Each tool call is one API request, and counts against the key’s rate limit.
  • The MCP server is read-only. It has no tool for POST /tasks or PATCH /tasks/{taskId}.
  • The API itself does not change.
​
6 November 2026
Tasks, and the first scopes that change data.
  • GET /task-boards lists your task boards with their columns and labels. GET /tasks lists the tasks on them, and takes boardId and updatedSince. Both need the new scope tasks:read.
  • POST /tasks adds a task and PATCH /tasks/{taskId} updates one: title, description, priority, due date, column and labels. Both need the new scope tasks:write. To complete a task, move it into its board’s done column.
  • A key reaches every board in its group, including restricted boards and the trustee duties board. Each board in GET /task-boards says its kind. On the trustee duties board every task is a trustee duty: adding one needs a dueDate, and creates the duty.
  • A change is recorded as made by the admin who created the key. In Scoutworks the task shows the key’s name, and when it last changed the task.
  • Send an Idempotency-Key header with POST /tasks, so a retry after a timeout cannot add the task twice.
  • Writes count towards a second limit of 30 changes a minute for each key. See Rate limits.
  • Two new error codes: subscription_required (402) when the group’s subscription has lapsed, which stops writes but not reads, and conflict (409) while a request with the same Idempotency-Key is still being processed.
  • A task’s description is free text, so the API never returns it.
​
5 November 2026
A figure that counts each young person once, and a fix to net growth, on GET /nodes/metrics.
  • New figure: young_people_count. It counts each young person with an active membership once, however many groups below your node they belong to. member_count is unchanged: it still counts memberships, so a young person in two groups counts in each.
  • young_people_count has a row per section. A young person counts once in each age group they are in, so its section rows can add up to more than all. Never add its value or ownValue across rows: read your own node’s row. It is counted directly each night, so it is never stale.
  • net_growth_12m changes value. A young person who joined and left inside the 12 months used to count as one leaver and no joiner, so a group with turnover showed a lower figure than it should. They now count as one joiner and one leaver: no change. Expect net_growth_12m to rise for groups where young people joined and left within the year.
  • Nights built before this release have no young_people_count rows, and keep the old net_growth_12m.
  • See Data definitions for exactly what each figure counts.
​
5 November 2026
Section figures and the parent on GET /nodes/metrics.
  • Each row now has section. all is the total, as every row was before. member_count and waiting_count also have one row per section: squirrels, beavers, cubs, scouts, explorers, network, and unassigned for those with no section. The sections sum to all exactly. net_growth_12m has all only. Nights built before this release have all rows only, so section=cubs on such a day returns no rows.
  • A new query parameter, section, picks the rows. It defaults to all, so a call that worked before gets the same rows. A row’s value already includes everything below it: to total rows yourself, add ownValue, never value. Pass a section (section=cubs) for its rows only, or section=any for every row.
  • Each row now has parentId: the node directly above groupId on the night the row was built. It keeps that value after a group moves district, so an older night reads as the tree stood then. null at the top of the tree, under a deleted node, and on every row built before this release: those nights did not record the parent.
  • Section counts are exact, like the totals.
  • Definitions corrected, counts unchanged. member_count and net_growth_12m count memberships, as they always have: a young person in two groups counts once in each, so a district total counts them twice. The descriptions used to say “young people”. Every figure is now defined on one page, Data definitions.
​
4 November 2026
Keys for districts, counties, regions and the national team, and the node endpoints they read.
  • A district or area admin creates a key in the district’s Settings → Integrations. It reads totals, never a person’s record.
  • GET /nodes/descendants lists the groups and nodes below yours that share data with you, at any depth. It needs nodes:structure:read.
  • GET /nodes/metrics lists one night’s totals (member_count, waiting_count, net_growth_12m) for your own node and each group or node below it that shares with you. Each row carries groupId and asOf. Narrow with childId, metric or day. It needs nodes:metrics:read.
  • The totals are built each night. A group that stops sharing, or moves district, shows in your totals within 24 hours.
  • GET /me now carries group.tier: group for a group key, the level of the node for a district or area key.
  • A group key gets 403 insufficient_scope on /nodes, and a district or area key gets the same on the group endpoints. See Keys for districts and above.
​
3 November 2026
More member detail under members.contacts:read, so a new member record can be created complete in another system.
  • gender: as the group recorded it, in lower case (usually male, female, other or prefer_not_to_say), or null.
  • address: the member’s home address (line1, line2, city, county, postcode), or null. Scoutworks holds one home address per member, given by the parents or carers, not one per parent.
  • parents[].phone: each parent or carer’s phone number, or null.
  • Every key that already holds members.contacts:read gets these fields from this release. No new scope. A group admin who does not want them shared can remove the scope from a key in Settings → Integrations → API keys.
​
3 November 2026
The badge catalogue, and a fix to the published type of a badge’s id.
  • GET /badge-catalogue lists every built-in badge and your group’s own custom badges, with the sections that can earn each one, the stage and series of a staged activity badge, and every requirement with a stable id, in the order the badge lists them. Badges of a nation your group hides (by its postcode, or its badge settings) are left out, as in the app. It needs badges:read.
  • Every badge now has key: the catalogue key of a built-in badge, for example badge_001, or null for a custom badge. Badge records carry it too, inside badge. Use it to map to another system such as OSM.
  • A built-in badge’s key and its requirement ids do not change between releases. A requirement id is the same one a badge record’s requirements uses.
  • Fix: the API reference said a badge’s id is a UUID. A built-in badge’s id has always been its catalogue key (badge_001); only a custom badge’s is a UUID. The reference now says it is a string. No value has changed.
  • A custom badge’s requirement wording is typed by a leader, so the catalogue leaves it out (description is null).
​
3 November 2026
Sync only what changed: updatedSince on GET /members, /events and /badges.
  • With updatedSince, a list returns only the records that changed at or after that time. A change to a member, their membership in your group or a linked parent’s own record counts. So does a change to an event, your group’s place on it, or a new RSVP. A badge record counts as changed when it, its member or its badge changes.
  • Each page carries nextUpdatedSince. Pass it as updatedSince next time. It is a little before your walk began, so no change is lost.
  • A sync does not report records that were deleted or left the list, parent links added or removed, or renames. Run a full read at least once a week. Pagination shows the whole loop, and the Sheets, Excel, n8n and Zapier recipes do it.
  • Without updatedSince, nothing changes.
​
3 November 2026
Requirement progress on badge records.
  • Each record from GET /badges now carries requirements: every requirement with recorded progress, with its id, status (not_completed, planned, in_progress or completed) and completedAt. A requirement not listed has not been started.
  • A requirement id comes from the badge definition, for example requirement_056, or for a custom badge it is the id of that badge’s requirement. It does not change between releases, so you can map it to another system.
  • It needs only badges:read. Leaders’ notes and sign-off notes are never included.
​
3 November 2026
A new list: GET /sections.
  • It lists your group’s sections and units, with the id, name and type (squirrels, beavers, cubs, scouts, explorers or network) of each. An Explorer unit has the type explorers.
  • active is false for a section the group has closed. Closed sections stay in the list, so you can still match an older record that names one.
  • The id is the same one that members, events and the waiting list use, so a sync can file each record under the right section.
  • It needs the members:read scope. Each member’s sections already shows these ids and names, so existing keys with that scope can read it at once.
​
24 September 2026
GET /me tells you more on your first call.
  • environment says which Scoutworks deployment answered: production, staging, demo or development. Demo holds only made-up data.
  • links.docs points to these docs, and links.try suggests a first list request that your key’s scopes allow.
  • The description of expiresAt now says that null means the key never expires.
  • Browsers can now read the RateLimit-* and Retry-After headers, so a web page can show how many requests are left.
  • The developer docs and the Try it playground can call the API from the browser.
  • A public sandbox key for the demo group.
​
Public beta
The first public version of the Scoutworks API.
  • Read endpoints: GET /me, /members, /events, /events/{eventId}/attendees, /badges and /waiting-list.
  • Scopes for each area, plus .contacts scopes that add dates of birth and parent details.
  • Cursor pagination, a fixed error shape and rate-limit headers.