This is actually my bug because I didn’t supply the date range
Doing this works as expected:
curl --location 'https://intervals.icu/api/v1/athlete/0/athlete-summary?start=2024-11-01&end=2024-11-24'
Ideally the API would report a 4xx bad request error instead of 500 (crash?)
Hi @david - is it possible to change the /api/v1/athlete/{{id}}/gear endpoint to include a date range?
This would allow me to determine the time and distance accumulated on the bike between the two dates.
Looking at my own gear stats, I see
Brompton 2110km 19h
Orca 12580km 276h
which don’t really make much sense. I really don’t think I can cycle 2k km on a brompton in 19hrs! 
Hi,
A bit of conceptual question about the API and data model:
Do I get it right, that the API is designed to track metrics in two ways:
Is there a way or plan to track 24x7 metrics, like HR, Stress and so on, assuming that integrations that are able to provide such data exist?
hi @david i think there is a bug in https://{{server}}/api/v1/athlete/{{id}}/activities?oldest=2024-11-03&newest=2024-11-10
The gear object is not populated correctly - it always lists the same gear.id and the other fields including name is null
You’re right, there is only the ID field being populated there. The rest are in the “gears” endpoint.
If you set a default gear, this will default to that gear.id each time.
If I do want to list the gears, I would match it. What I do is get the gears from the gear endpoint and match it with the gears ID on the activity.
edit: Read some of your earlier post - What you’re wanting to do, i don’t believe the current endpoints supports it. There is a # of activities, but AFAIK there is no linkages to the actual activities that are using those gears.
I suggest using the list view for your purpose. And then using the Filter for the gear that you want
if you notice on the bottom, there’s already a helpful total for dist and time.
It’s not so much a bug but undocumented behaviour Only the gear id is filled in for performance reasons. If you need the full gear object you can make a new call to the list gear endpoint.
Looking up the gear_id lookup would be fine, however I’m seeing the same gear ID for two rides when only one of the bikes (gear ID is correct)
This bug means that I can’t detect which bike was used for the ride using the API call.
You can reproduce this with the following API call
'https://intervals.icu/api/v1/athlete/i189303/activities?oldest=2024-11-17&newest=2024-11-18'
The ride on the 17-Nov should have gear.id == b10966650
and the ride on 18-Nov should have gear.id == b12116607
But the response from the api is:
[
{
"id": "12938769888",
"start_date_local": "2024-11-18T07:16:54",
...
"gear": {
"id": "b10966650",
...
},
...
"icu_variability_index": null
},
{
"id": "12920827048",
"start_date_local": "2024-11-17T09:18:20",
...
"gear": {
"id": "b10966650",
...
},
"perceived_exertion": null,
...
"icu_variability_index": null
}
]
Thanks
Those activities both have the same gear in the db? I just ran some SQL to check.
id | gear_id | start_date_local | name | deleted
-------------+-----------+----------------------+--------------+---------
12920827048 | b10966650 | 2024-11-17T09:18:20Z | Morning Ride |
12938769888 | b10966650 | 2024-11-18T07:16:54Z | Morning Ride |
Thanks for checking - you’re right something weird is going on as each bike has its own Wahoo head unit which should be setting the gear (bike) correctly
I’ll keep investigating and sorry for wasting your time!
After updating Strava and resyncing in Intervals, things are looking a lot better now. Thanks for all your help David
Not at the moment. I hadn’t thought about 24x7 metrics. Quite a few services do delivery such stuff but Intervals.icu only uses the summary data for the day. I would need to poke around and see how space efficiently such data could be stored. If it is only every 15m or something then it would be possible.
Based on the current API design, it could be an another type of custom item, and then a way to submit the data via Wellness API like endpoint.
In regards to the actual data, I was planning making a Garmin Connect IQ app which can submit health data (it’s available with user’s permission) to the API endpoint
@david has the ListActivities API response changed when the activity originates from Strava? (Actually my activities originate from other apps that are collected in Strava)
https://intervals.icu/api/v1/athlete/xxxxx/activities?oldest=2024-11-03&newest=2024-11-10
I’m now seeing this response from the API which is different from a couple of days ago
{
"id": "12847086233",
"icu_athlete_id": "xxxxx",
"start_date_local": "2024-11-07T18:53:20",
"source": "STRAVA",
"_note": "STRAVA activities are not available via the API"
}
I know you mentioned somewhere that you didn’t want people proxying activities via Intervals.icu, but having to create two integrations; one for Intervals.icu and one for Strava is going to be a real pain
Is there any way I can source Activities without having to create a Strava integration too? Thanks
Looks like this is the way moving foward with the new Strava updates on their T&C. No “Proxying” of the data from Strava via other sites.
Will just have to show users that this is the new “error” and why it’s happening and persuade them to drop strava (provided they have a choice)
You need to try get the Strava stuff into Intervals.icu directly from the system it originated on instead of going via Strava. Unfortunately that is the only way.
Ok understood.
If there is an integration between Wahoo and intervals, i would use it over Strava - I’ve just cancelled my paid subscription with them (Strava).
Btw @david could you modify the get activities API to provide the non Strava data which i presume are the icu_… prefixed ones? My assumption is that because there are calculated by Intervals, it doesn’t prevent you making those available.
If you can that would be amazingly helpful rather than my having to reinvent the wheel to calculate HRTSS or TSS for example
Thanks!
As FYI to those facing this new challenge. This is the data returned from the Intervals.icu API on activities which are solely transferred to Intervals.icu from Strava.
(T&C From Strava forbids sites from proxying “THEIR??” data from Strava API to other services)
I’m working to code to show an error message to the user noting why they’re not seeing their data.
The Strava restriction appears to affect many of activity related Intervals APIs:
https://{{server}}/api/v1/athlete/{{id}}/activities
https://{{server}}/api/v1/activity/{{activityid}}
https://{{server}}/api/v1/activity/{{activityid}}/power-histogram
etc …
I’m able to retrieve my activity data from Strava using their API but it is a hassle getting all the OAuth stuff to work, and having a token that needs refreshing every 6 hours
I still think that there is a significant delta between what Strava returns, and what the original https://{{server}}/api/v1/activity/{{activityid}} API returned. It would be great if @david is able to reinstate all of the non Strava fields; specifically those that are computed in Intervals or sourced elsewhere like the weather for example
"average_weather_temp": 9.957777,
"min_weather_temp": 9.949999,
"max_weather_temp": 9.969877,
"average_feels_like": 8.561321,
"min_feels_like": 8.486321,
"max_feels_like": 8.6098,
"average_wind_speed": 1.246676,
"average_wind_gust": 2.8502395,
"prevailing_wind_deg": 90,
"headwind_percent": 19.877048,
"tailwind_percent": 17.008196,
"average_clouds": null,
"max_rain": null,
"max_snow": null,
I have to be very careful here or Intervals.icu will lose access to the Strava API. Lots of people are still getting activities via Strava.
I have opened the weather summary endpoint for Strava activities.
Completely understand your pov and certainly don’t want to risk loss of access.
Thank you for making the weather data available 
Do you feel comfortable creating a new endpoint (say) /v1/getIntervalComputed/{{activityid}} that is able to return the following fields (which do not exist in the Strava activity and originate from Intervals or are computed in Intervals):
icu_rolling_ftp
icu_rolling_ftp_delta
icu_atl
icu_ctl
icu_ftp
icu_hr_zones
icu_resting_hr
icu_weight
icu_power_zones
icu_sweet_spot_min
icu_sweet_spot_max
Thank you