Strava API Changes in 2026: Can Developers Still Get Access?

Developers can still access the Strava API. A new application starts with access for one athlete and can be upgraded to ten without review. Standard Tier developers need a Strava subscription. Serving more than ten athletes requires approval under Strava’s published access rules.

Existing approved applications keep their approved athlete capacity within the Standard range. They still have to meet the subscription requirement and account for the endpoint changes that took effect on September 1. An approval obtained before the overhaul does not preserve every feature the API used to provide.

Strava announced the overhaul on June 1, saying that growing application demand, scraping and misuse had forced it to rework reviews. Small projects now have a self-service entry point, while larger applications face review and closer scrutiny of data use.

The distinction between starting a project and launching it to customers matters. Ten athletes is the self-service threshold. Standard Tier can support up to 9,999 athletes after review. Applications approved for 10,000 or more athletes fall into Extended Access. An app with approval for 500 athletes does not need to shrink to ten; a new app with ten connected testers cannot assume it will receive approval for 500.

Strava guarantees neither review deadlines nor capacity increases. Resolve approval before committing to a launch beyond your current limit.

The subscription requirement started on June 1 for new Standard developers and June 30 for existing Standard developers. Extended Access is exempt from that requirement. If you already have a Strava subscription, the published FAQ says there is no additional API fee for Standard access. Paying for the subscription does not buy an automatic capacity increase.

The self-service upgrade also increases the request allowance. It provides 400 requests per 15 minutes and 4,000 per day overall, with a separate allowance of 200 per 15 minutes and 2,000 per day for non-upload requests. These limits apply to the application across its connected athletes. If your beta imports activity history for several people at once, that shared allowance matters well before you reach a large user count.

September brought the first endpoint removals. The June announcement described what was coming; the live changelognow records what has happened.

For an application built around a club's activity feed or membership roster, those removals affect the product itself. The remaining Club endpoints serve different purposes: GET /clubs/{id} returns club details, and GET /athlete/clubs lists clubs associated with the authenticated athlete. Neither supplies a replacement club activity feed or membership roster.

Segment discovery needs a separate access check. The reference for GET /segments/explore requires Extended Access and granted permission. A Standard subscription does not unlock it, and entering Extended Access is not sufficient by itself. If your application uses a map to discover nearby segments, confirm permission for that endpoint before treating the feature as available.

Strava’s current API policy prohibits using API data in AI applications, including prompts, embeddings and retrieval-augmented generation. Derived and anonymized data are covered. Keeping data out of training does not establish permission to use it as model context.

AI restrictions predate this overhaul. In November 2024, Strava said its previous terms already prohibited model training and development. The current policy names additional operations explicitly, making the intended AI feature's full data flow relevant.

Strava needs to clarify what smaller apps may display. Policy section 6.1 suggests an exception for capacities up to 9,999; section 2.3 and the agreement restrict display to the contributing user. The agreement controls conflicts. Get clarification before relying on the exception for shared dashboards or leaderboards.

The current policy also limits caching to seven days and restricts storage beyond that cache. Account for this when designing how your application retains activity history.

The June announcement also restricts applications routing Strava data through third-party intermediary platforms and says affected applications will receive separate instructions. If another service makes Strava requests and routes data on your application's behalf, confirm that the specific arrangement is authorized. A successful connection alone does not settle that question.

The next technical deadline is June 1, 2027. The current changelog specifies a new API base URL, https://api-v3.strava.com, becoming available on January 4, 2027. That leaves a migration window before the announced deadline. Keep using the current host until the new one is available, then test your integration against it.

One change can be implemented now under the updated deauthorization documentation: POST https://www.strava.com/oauth/revoke is already available. It replaces oauth/deauthorize, which retires on June 1, 2027. The new endpoint authenticates the application using HTTP Basic authentication with its client ID and secret, accepts an access or refresh token, and returns an empty HTTP 200 response on success. Existing disconnect logic should be tested against that response format.

The 2027 changes also require authorization tokens for API resource requests to be sent in request headers. OAuth remains the authentication system; the work concerns how your integration sends tokens, revokes access and addresses API requests. These are scheduled migration obligations, distinct from the September removals already in effect.

Our view at Terra is straightforward. People generate their activity data. They should choose which applications receive it. The fact that a platform stores that data should not give it control over that choice, or permission to make sharing difficult.