Changelog

Every change to the API, the console and these docs that you can see from outside — a new endpoint, a new field, a new provider, a breaking change — lands here. How we bill and how a plan is bought is not part of the API; that lives on pricing.

A date here is a release, not the day a particular commit landed — everything that shipped together is listed together. Breaking marks a change that can stop working code from working; there is a paragraph under each one saying what to do about it.

Want something that isn't here yet? Ask for it on the roadmap — it is the same board this changelog is written against.

2026-09-18#

• Garmin wellness history now backfills on connect. The wellness docs have said history on connect applies to wellness as well as activities. On Garmin it did not: a user who granted historical export got years of activities and no wellness history at all. We now request Garmin's Health API history for every summary type except epoch — sleep, hrv, daily, stress, respiration, pulse_ox, fitness, body_composition, blood_pressure, skin_temperature and health_snapshot. Garmin serves only one month of wellness history, against years of activities, so expect about the last four weeks. Each summary arrives as an ordinary wellness.created, with its own old calendarDate. The user needs both historical and health export granted. Users who connected before today are backfilled in the background over the coming days, with no reconnect needed.

• Fitbit is the seventh provider. POST /v1/connect accepts fitbit, and it covers Pixel Watch too. It is built on the Google Health API, not the Fitbit Web API that Google is retiring, so a user who linked Fitbit elsewhere through the old API consents again here. Finished workouts arrive as activity.created with a TCX file — Google exports no FIT. Sleep, resting heart rate, HRV, breathing rate and SpO₂ arrive as wellness.created (sleep, daily, hrv, respiration, pulse_ox). Partial consent is honoured: each kind is read only if the user granted it, and scope on the connection says what they granted. No workout push, and no history on connect yet. The support matrix has the current shape.

2026-09-14#

• The Stridee CLI: real deliveries on localhost, with no tunnel. stridee listen --forward-to localhost:3000/webhooks opens an outbound connection to us and acts as one more webhook endpoint on your account for as long as it runs. Every event your account emits is POSTed to your local server exactly as production gets it: the same sealed envelope, the same webhook-id, webhook-timestamp and webhook-signature headers. The CLI never decrypts anything, so the code under test is your handler's own verify and decrypt. Each delivery prints one line saying what your handler answered and whether it echoed the nonce, and shows up in the console's delivery log like any other.

  stridee login has no token. The CLI generates an Ed25519 keypair, sends only the public half, and approving the code in the console registers it as a signing key. It shows under Keys as Made by the Stridee CLI, and stridee logout revokes it. stridee trigger ping pings running listeners only, never production endpoints. Listening does not take deliveries away from your production endpoints: the listener gets a copy. Listeners do not count toward your endpoint limit, and an account can run up to five at once.

  Install it with curl -fsSL https://download.stridee.com/install.sh | sh — macOS and Linux, Intel and ARM, one static binary and nothing else left on the machine. Every command, with its options and examples, is in the CLI reference, generated from the CLI's own definitions so it matches what stridee <command> --help prints.

• Workout pushes say why they did not land. Each entry in pushes[] now carries reason, a stable code to branch on, next to error, which is still a sentence you should not parse. failed covered three problems with three different fixes, and reason separates them: not_permitted (the athlete connected but did not grant workout access, so they have to reconnect, and retrying won't help until they do), not_connected, and provider_error (the only one worth a PATCH). unsupported and schedule_failed complete the set. A clean push has no reason at all. Pushes made before this release have been backfilled.

  A Garmin push that Garmin answers with 401 or 403 is now reported as not_permitted instead of a provider refusal. That means the athlete switched Workout Import off in Garmin Connect before we heard about it. The error sentences for Garmin and Wahoo now say what to ask the athlete to do. The console's Workouts screen shows the reason under each push. Workouts has the full table.

• COROS takes undated workouts. A workout with no scheduled_date used to come back unsupported for COROS, because the COROS calendar had nowhere to put it. It now goes to the athlete's COROS workout library and reports synced. A dated workout still has to fall between today and a year ahead.

2026-09-09#

• Zepp publishes wellness — sleep, and sleep only. An Amazfit night now arrives as a wellness.created event with the stage breakdown, Zepp's own sleep score, finality and the per-stage timeline behind series_url. Zepp's health API mirrors Garmin's field for field, so code that already reads Garmin sleep reads this with no branch, and zepp is now a value the provider filter on GET /v1/wellness accepts.

  There is no daily from a Zepp watch — steps, calories and resting heart rate are not on their health push. Overnight HRV is on it and is deliberately not published: Zepp documents no schema for it, and we would rather serve nothing than a resting-HRV number nobody has verified. Wellness has the per-provider shape.

• COROS history on connect now reaches your event stream. The walk existed before but wrote first-party rows only; it delivers through the same fan-out as live activities now, so past workouts arrive as ordinary activity.created events with nothing marking them as historical.

  How deep is the athlete's choice, not ours. COROS's consent screen carries a checkbox offering access to their previous workouts — left alone it grants 90 days, ticked it grants their whole history, and we walk 30-day windows back until COROS answers 5011. Nothing in the API says which grant you got, so we cannot tell you in advance how far a given user goes. Two caveats, both COROS's: the deep grant expires 24 hours after binding, so history is collected at once rather than offered as a setting later, and COROS serves only what was recorded on a COROS device — a FIT imported through Training Hub is never listed. Provider support & limits has both in full.

• Wahoo connections replay history, up to five years of it. Connecting a Wahoo athlete now delivers their past workouts as ordinary activity.created events — same shape, same file block, nothing marking them as historical. It was the one connectable provider that started at the athlete's next activity.

  Wahoo publishes no backfill endpoint, so this is a pull rather than a replay, and their rate limit is per application rather than per athlete. A heavy athlete's full history can therefore take up to a few days to finish arriving; recent workouts come first, and live ones are never delayed behind it. Provider support & limits has the current depth and the caveat in full.

2026-09-06#

• Hammerhead is the sixth provider. POST /v1/connect accepts it and finished rides arrive as activity.created like any other. It has no wellness surface to publish — it is a bike computer — and workout push is not built against it yet, so naming it on POST /v1/workouts is a 422. The support matrix has the current shape.
• Provider support & limits is now a page: /docs/providers. It says, per provider, which endpoints work, how far back history reaches and what is missing. It replaces asking in Discord, which was the way to find this out before.

2026-08-23#

• Zepp is a connectable provider.

• The platform moved to its own host, platform.stridee.com. The docs, the console and this page all live here now, and stridee.com/developer/* is no longer the address.

  Breaking, for bookmarks and links only. The API host is unchanged — nothing your code calls has moved. Update links you have published; the old paths do not serve the console.

2026-08-16#

• Your name and logo on the consent screen. Set them on Branding and the page an athlete sees when they connect a watch says who they are connecting it to. The name and the logo are shown together or not at all.

2026-08-09#

The first public shape of the platform.

• GET /v1/activities, across every connected provider, in one normalized shape.
• Encrypted deliveries. Every webhook body is sealed to your public key as a JWE and signed with a detached JWS you verify against our published JWKS. See Encrypted deliveries and Verifying a delivery.
• Request logs, on Logs — every signed call to /v1/*, including the ones we refused. A 401 you cannot explain from your side is a row you can read from ours.
• Connected accounts, on Accounts, keyed by your own external_user_id.
• Resending a delivery, per delivery, from the endpoint that received it. Nothing retries automatically — a person presses a button. Design your outage handling for that.
• Registered redirect URIs, on Redirect URIs. POST /v1/connect will only return to a URL on that list.
• Every platform id is a UUID v4 — key ids, webhook ids, event ids, delivery ids. They are opaque: nothing in the string tells you what it names, so store them as given, compare them whole, and keep the id next to the thing it belongs to.