Introduction

The Stridee API gives your product one integration instead of 20+. Your users connect whichever 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.

What it covers#

Six providers — Garmin, COROS, Polar, Wahoo, Zepp and Hammerhead — behind one connect call, with more on the way.

The differences between them are larger than a list of names suggests: wellness and workout push are different subsets of the six, and history on connect ranges from years of it on Garmin to none at all on Hammerhead. All of that — what each provider serves, how far back it backfills, what holds on every provider, and how to use each manufacturer's name — is on Provider support & limits. That page is generated from the constants the API enforces, which is why it is a link rather than a second table here.

Where a provider does not send something, the field is absent rather than estimated — a null you can branch on is worth more than a number nobody measured.

How it fits together#

Four pieces, and they map onto the console's sidebar.

• 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 Connecting a device.
• Encryption keys. You hold an X25519 private key; we hold the public half. There is no bearer token and no shared secret anywhere in this, 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.

Every id in that picture — a key, an endpoint, an event, a delivery — is a UUID v4, 36 characters, lower case. There is no prefix and nothing in an id tells you what it names, so store them as a uuid column or a plain string and never parse one. Two ids are worth keeping apart: an event id is the thing that happened, and a delivery id is one endpoint's copy of it, which is what arrives as webhook-id and what you dedupe on. One event sent to three endpoints is one event id and three delivery ids.

{
  "id": "c41e9b02-7a3d-4e58-8f19-6b0d2c85af73",
  "type": "encrypted",
  "enc": "eyJhbGciOiJFQ0RILUVTIiwiZW5jIjoiQTI1NkdDTSIsImtpZCI6IjVhOGYzMWQ2LTBjOTQt…"
}

Standard JWE compact, so opening it is a library call rather than homegrown crypto. The Quickstart does the whole path in about fifteen lines.

Getting access#

The platform is self-serve. Plans start at €32.50 a month billed annually, every one of them opens with a two-week free trial, and every one of them is the whole API — see pricing. What separates the tiers is how many of your users may connect a watch, never which endpoints you may call.

Checkout creates your account and opens the console on it: pick a plan, pay, then sign in with the address you paid with. There is no application to wait on and nothing to be approved. Cancelling is a button in the Stripe billing portal, and any charge is refundable for 30 days.

What is not here yet#

Keys, webhook endpoints, deliveries, the event stream, connected accounts, request logs, GET /v1/activities, workout push and wellness are live. What is not — laps, per-second streams, a canonical re-encoded FIT, and the providers a connect call cannot name yet — is listed in one place on Provider support & limits. The screens for anything unbuilt say so plainly rather than showing a plausible zero — a registered endpoint shows no delivery history because none exists, not because it is quiet.

Where to go next#

• Quickstart — a key, an endpoint, a delivery you can read.
• Webhooks — receiving events, start to finish.
• Encrypted deliveries — the scheme, and rotating a key.