Get started

The Stridee API gives your product one integration instead of 20+. Your users connect the watch, bike computer or platform they already own, you read their finished activities in a single shape, and you push structured workouts back to the watch — with one set of credentials, one webhook handler and one set of rate limits.

How it fits together#

Four pieces, each a screen in the console.

• Connections. You send us your own id for one of your users and get back a URL to redirect them to. They consent at the provider, and from then on their data is yours to read. You never hold a provider client secret or implement an OAuth callback — see Connect a device.
• Keys. You hold the private halves, we hold the public ones: an Ed25519 key signs your requests, and an X25519 key is what deliveries are sealed to. There is no bearer token and no shared secret anywhere, which is why nothing on the keys screen is masked.
• Events. Something happens on a provider — a run finishes, a token expires — and we turn it into an event with a stable type and an id.
• Webhooks. We deliver those events to your endpoint, sealed to your key so the body is readable by your service and nothing between us and it.

What each provider serves#

Seven providers sit behind one connect call, and they differ more than a list of names suggests: wellness and workout push are different subsets of the seven, and history on connect ranges from years on Garmin to none on Hammerhead. Where a provider does not send something, the field is absent rather than estimated.

Provider support & limits has all of it, generated from the constants the API enforces — including what is not live yet: laps, per-second streams and a canonical re-encoded FIT.