Skip to main content

I’ve been using the api/v3/activities/{id}/streams?keys=time,watts in a web application for roughly 3 years with no problems. This last week, suddenly, the exact same API call seems to be returning data with gaps: not starting with the same timestamp as the .fit file (ie, missing the first 200 or so values) and skipping one or two seconds of power data throughout the stream (ie, like Swiss cheese, full of holes)

Is this my problem or Strava??

I just encountered the same problem in my code. It seems like the “get_activity_stream” changed its default behavior: I am pretty sure that it returned data with the full resolution (i.e. 1 data point per second) the last time I used it (about half a year ago). Now, max.10000 points seems to be the default.
When your activity is longer than 10000 seconds, there will be jumps. 

I now have the problem that i need a vector for the “moving time”. In the past, this was just [1,2,3,4,…,N]. 


Interesting. Thanks for confirming the ~10,000 limit and the gaps.

I’m not sure how this API function can be considered useable now. Large chunks of data -- even sections with movement and power values -- are just missing; I don’t see a way to do anything reliable with the data that’s left.


@Emily_A Is the team responsible for the API aware of this regression? I can confirm that the api/v3/activities/{id}/streams endpoint returns only a subset of under 10.000 data points per type with irregular gaps in it. In example an activity with a moving time of 12880 seconds formerly returned 

0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20

for the first 21 data points in the time stream. Now the same activity returns

0,2,4,6,7,9,10,12,14,15,16,18,19,20

thus making it more or less unusable for any serious analyzing.


@Jan_Mantau thanks for the flag. We’re aware and taking a look. 


Hi all, this should be resolved!