SpectrumStrategy #1009 wants an AI brief on a team built from their previous events. The client cannot supply the input.
What exists
Everything is event-scoped: getEvent, getEventTeams, getEvents, getEventMatches, getEventTeamsBasic. There is no way to ask "what has team 3847 done this season" or "across seasons", and nothing in the consuming app fetches a team's results from any event other than the active one.
What to add
Two methods, both against endpoints Statbotics already exposes:
getTeamEvents(int team, {int? year}) over GET /v3/team_events?team={team}. Returns StatboticsTeamEvent, the same model getEventTeams already decodes, so this needs no new model at all: same endpoint, same element type, different filter. That is most of the value for #1009 and it is a small change.getTeamYears(int team) over GET /v3/team_years?team={team}, for season-over-season trends (#1010). This one does need a new model.
Sort newest first, and cap limit the way the existing methods do.
Blocked on the API being reachable
The Statbotics API has returned HTTP 500 on every /v3 endpoint since 2026-06-15. Verified again on 2026-08-14: teams?limit=1, events?year=2024, team_events?team=3847 and team_years?team=3847 all 500 with an empty body, while thebluealliance.com and statbotics.io itself answer 200.
Upstream: avgupta456/statbotics#414 and #418, open with no maintainer response.
That matters here specifically. Adding a method means pinning the exact response field names, and there is no way to observe them right now. Writing them from memory or from docs and tagging a release is how a client ships with the wrong keys and every field decodes to null. team_years is the riskier of the two, since its shape is not already proven by an existing model.
So: do not start this until GET /v3/team_events?team=254 returns 200 and its body can be read. getTeamEvents could arguably go first on the strength of the shared model, but it still cannot be verified end to end.
When it lands
Per the consuming app's client-package conventions this is a version bump, a changelog entry, a tag and a GitHub release, then a separate pin bump in the app. Related risk writeup: Spectrum3847/SpectrumStrategy#1020.
SpectrumStrategy #1009 wants an AI brief on a team built from their previous events. The client cannot supply the input.
What exists
Everything is event-scoped:
getEvent,getEventTeams,getEvents,getEventMatches,getEventTeamsBasic. There is no way to ask "what has team 3847 done this season" or "across seasons", and nothing in the consuming app fetches a team's results from any event other than the active one.What to add
Two methods, both against endpoints Statbotics already exposes:
getTeamEvents(int team, {int? year})overGET /v3/team_events?team={team}. ReturnsStatboticsTeamEvent, the same modelgetEventTeamsalready decodes, so this needs no new model at all: same endpoint, same element type, different filter. That is most of the value for #1009 and it is a small change.getTeamYears(int team)overGET /v3/team_years?team={team}, for season-over-season trends (#1010). This one does need a new model.Sort newest first, and cap
limitthe way the existing methods do.Blocked on the API being reachable
The Statbotics API has returned HTTP 500 on every
/v3endpoint since 2026-06-15. Verified again on 2026-08-14:teams?limit=1,events?year=2024,team_events?team=3847andteam_years?team=3847all 500 with an empty body, while thebluealliance.com and statbotics.io itself answer 200.Upstream: avgupta456/statbotics#414 and #418, open with no maintainer response.
That matters here specifically. Adding a method means pinning the exact response field names, and there is no way to observe them right now. Writing them from memory or from docs and tagging a release is how a client ships with the wrong keys and every field decodes to null.
team_yearsis the riskier of the two, since its shape is not already proven by an existing model.So: do not start this until
GET /v3/team_events?team=254returns 200 and its body can be read.getTeamEventscould arguably go first on the strength of the shared model, but it still cannot be verified end to end.When it lands
Per the consuming app's client-package conventions this is a version bump, a changelog entry, a tag and a GitHub release, then a separate pin bump in the app. Related risk writeup: Spectrum3847/SpectrumStrategy#1020.