Stridee
Stridee Docs

Users & connections

Read back who is connected, disconnect a provider, and rename or forget one of your users.

Everything after the link. Connect a device gets a user connected; this page is the two lists that result — connections, one per authorization at one provider, and users, one per person — and how to change or end either.

Reading connections back

HTTP
GET /v1/connections?external_user_id=user_4821 HTTP/1.1
200
{
  "connections": [
    {
      "id": "a2f81b60-3c47-49d5-b8e2-70a4c9f13d85",
      "user_id": "6d3f0c11-90ab-4e77-9c25-1b8f5a2e40d9",
      "external_user_id": "user_4821",
      "provider": "coros",
      "status": "active",
      "scope": null,
      "connected_at": "2026-08-05T11:16:44Z",
      "revoked_at": null
    }
  ],
  "has_more": false,
  "next_starting_after": null,
  "total": 1
}

Omit the filter for every connection, newest first (Paging). One row per authorization, so a user with two watches is two rows. Disconnected ones are not listed.

  • status is active or reauth_required — the provider stopped accepting our credentials. Ask the user to reconnect; don't forget them. The account.reauth_required event is your cue, and the only notice anyone gets.
  • scope is what the user actually granted, verbatim, or null where the provider doesn't say (COROS, Polar).

What you don't get

The provider's own id for the user is never returned. Two developers serving the same person could otherwise join their user tables on it.

Disconnecting

HTTP
DELETE /v1/connections/a2f81b60-3c47-49d5-b8e2-70a4c9f13d85 HTTP/1.1

204, or 404 if it isn't yours or is already gone. Your access ends immediately and an account.disconnected event goes out, even though you asked.

The user's authorization at the provider is only revoked if yours was their last connection through Stridee — one authorization can back several products built on us, and revoking it would silently break the others.

Letting your user do it

If you'd rather not build a settings screen, mint them a link:

HTTP
POST /v1/connections/manage-link HTTP/1.1

{ "external_user_id": "user_4821" }
200
{
  "manage_url": "https://api.stridee.com/connections/manage?token=…",
  "expires_at": "2026-09-04T11:16:44Z"
}

It opens a page listing that person's connections with you, each with a disconnect button. The link is the credential, like a password-reset link: it lasts 30 days, so mint a fresh one per visit. Disconnections made there arrive with "revoked_by": "end_user" in data.

Your users

Everything above is about connections. /v1/accounts is the other axis: one row per person, whether or not they ever connected anything.

HTTP
GET /v1/accounts?external_user_id=user_4821 HTTP/1.1
200
{
  "accounts": [
    {
      "id": "6d3f0c11-90ab-4e77-9c25-1b8f5a2e40d9",
      "external_user_id": "user_4821",
      "providers": ["coros"],
      "status": "active",
      "connected_at": "2026-08-05T11:16:44Z",
      "activities": 47,
      "last_event_at": "2026-08-07T06:02:11Z",
      "created_at": "2026-08-05T11:14:02Z"
    }
  ],
  "has_more": false,
  "next_starting_after": null,
  "total": 1
}

Omit the filter for everyone, most recently active first (Paging). status rolls up their connections: active, reauth_required, revoked, or pending — sent a link and never finished. Pending users have no connection, so this is the only list they appear in.

GET /v1/accounts/{id} returns one user with every connection, revoked ones included, and their recent events.

Changing your id for someone

Your user table got re-keyed and user_4821 is now usr_01J9X…. Tell us:

HTTP
PATCH /v1/accounts/6d3f0c11-90ab-4e77-9c25-1b8f5a2e40d9 HTTP/1.1

{ "external_user_id": "usr_01J9X..." }

Nothing else changes: same user_id, same connections and history, no new consent. 409 if another of your users already has that id — we don't merge.

Forgetting a user

HTTP
DELETE /v1/accounts/6d3f0c11-90ab-4e77-9c25-1b8f5a2e40d9 HTTP/1.1

204, and everything you hold about that person is gone: your id for them, their connections and consents, any management link, their events on your stream, and your access to their activities. Connections are revoked under the same last-connection rule as above. The athlete themselves, and anything another developer holds, are untouched.

You get one account.deleted event — not a disconnect per connection — with the ids in data and no top-level user_id:

account.deleted
{
  "user_id": "6d3f0c11-90ab-4e77-9c25-1b8f5a2e40d9",
  "external_user_id": "user_4821",
  "connections_revoked": ["a2f81b60-3c47-49d5-b8e2-70a4c9f13d85"]
}

The id is then free: connecting it again creates a new user with no history.

Adding a second provider

Call /v1/connect again with another provider and the same external_user_id: one user, two connections. Your ids are opaque to us, so user_4821 and 4821 are two different people — pick one form and keep it.

Something wrong or missing on this page? Tell us in Discord. Need something the API doesn’t do yet? Request it on the roadmap.