The Strava Activities API: A Complete Consumer Surface

The Strava Activities API: A Complete Consumer Surface

The Strava Activities API creates, reads, updates, and deletes workout activities — the recorded runs, rides, and swims that are the core object of the platform. Base URL https://www.strava.com/api/v3.

Its catalog entry carries nine properties, and the composition is what makes it worth writing about: OpenAPI, Documentation, Authentication, GettingStarted, RateLimits, Webhooks, AsyncAPI, GraphQL, and APIs.json.

The complete set

Most APIs in the catalog carry an OpenAPI and some documentation. This entry names four things separately that most providers leave implicit:

  • Authentication as its own property, not a paragraph in the docs
  • RateLimits as a described surface rather than a number in a footnote
  • Webhooks as a first-class event surface
  • AsyncAPI alongside the OpenAPI, describing what pushes as well as what pulls

That combination — auth, rate limits, webhooks, and an event specification — is the full set an integrator needs and it is genuinely uncommon. It is a more complete description than most enterprise APIs carrying ten times the operations.

Why consumer APIs get this right

Strava’s API consumers are third-party app developers building training analytics, route planners, and club tools on someone else’s data. That relationship has two properties that force good description.

First, the developers are outside the building and always have been. There is no internal team quietly sharing tribal knowledge about the auth flow. Everything has to be written down or nothing gets built.

Second, rate limits are the binding constraint. A consumer platform serving thousands of third-party apps against millions of athletes has to be explicit about quotas, because the alternative is a developer discovering the limit by taking down their own app in production. Publishing RateLimits as a described property is self-defence.

The webhook point, again

This week’s AsyncAPI piece found only 661 providers describing an event surface out of more than 25,000. Strava is one of them, and the reason is structural: activities arrive when an athlete finishes a workout, not when your poller happens to run. An app that polls for new activities is an app that is either late or wasteful. The webhook is the integration.

That is exactly the case where an AsyncAPI earns its keep, and it is why the providers who describe events well are so often the ones where events are the primary signal.

Takeaway

Nine properties covering auth, rate limits, webhooks, and event specification on a single consumer API. Strava describes its integration contract more completely than most enterprise vendors, because its developers were never insiders and its rate limits were never negotiable.

See it at developers.strava.com, and the catalog entry at apis.io/providers/strava/.

← Profiling Palo Alto Networks: 168 APIs of Security Surface