Skip to main content

I'm currently working on integrating my climbing app with Strava, and I've hit a bit of a roadblock. When I manually create an activity on Strava through the browser, I have the option to enter the elevation. However, when I try to do the same thing programmatically using the createActivity API, I can't seem to find an option to specify the elevation.

This is crucial for my climbing app's functionality, and without it, integrating with Strava is kind of pointless. Can anyone shed some light on what I might be missing here? Any help or insights would be greatly appreciated. Thanks in advance!

You have to use the uploads endpoint for that and upload the activity file that contains the elevation. The manual activity was only ever suited for indoor activities or as a workaround for missing parts of an outdoor activity.


I did try to upload a gpx file with elevation data, but Strava "corrected" the elevations, overwriting the provided ones.  Is there any documentation available from Strava about the necessary structure of those uploaded files?

 


@Jan_Mantau wrote:

The manual activity was only ever suited for indoor activities or as a workaround for missing parts of an outdoor activity.


This doesn't seem to be a limitation of a manual activity, but a limitation of the API since elevation can be specified when creating a manual activity using the website.



@ibex_climbs wrote:

This doesn't seem to be a limitation of a manual activity, but a limitation of the API since elevation can be specified when creating a manual activity using the website.


or perhaps it's supported in the API and it's just missing in the documentation!?


I’ve tried passing both total_elevation_gain and elevation_gain as parameters but no dice. Anyone know if this is still a limitation or there’s a way now to create an activity via the API with elevation gain?


I’ve tried passing both total_elevation_gain and elevation_gain as parameters but no dice. Anyone know if this is still a limitation or there’s a way now to create an activity via the API with elevation gain?

For activities with GPS data Strava calculates the elevation from that. The exception are devices with a trusted elevation measurement, in that case Strava takes over the elevation from them without change.


In another thread, someone had mentioned that the elevation has to come from a “trusted source” - not sure which apps are considered trusted / what criteria must be met, but perhaps it explains why it doesn't work for you: 


I’ve tried passing both total_elevation_gain and elevation_gain as parameters but no dice. Anyone know if this is still a limitation or there’s a way now to create an activity via the API with elevation gain?

For activities with GPS data Strava calculates the elevation from that. The exception are devices with a trusted elevation measurement, in that case Strava takes over the elevation from them without change.

Thanks. But I’m not really sending my data from a device, I’m calling the “create activity” API from a microservice or even Postman. How do I get Strava to recognize and accept the elevation gain parameter I’m passing?


@elvinpedro As the original post states this is not possible with the create activity endpoint.


@ibex_climbs & ​@elvinpedro 

If you want to include elevation when creating a manual activity, the field name/parameter to use is elev_gain and the value is in meters.

 


@ActivityFix That’s a real insider tipp! How did you find that elev_gain parameter?


For any API endpoints which have an equivalent form on the website (e.g. edit activity, manual activity creation), you can look at the page source with the developer console to get field names (and the dropdown options for values you select from a list, e.g. for getting the sport types, or the map names). There’s no guarantee they are all supported by the API, but it often gives a hint to what you can try.

In my screenshot below for the manual activity creation page, you can see in green the distance field, which is documented, along with the elev_gain field which is not documented. As I mentioned, they don’t always match, for example the elapsed_time_[hours|minutes|seconds] fields in red don’t actually exist and are instead a single combined value called elapsed_time in the API.

Usually what I do is grab the names of the fields I want and use postman to test them all at once. Whichever ones go through are good. The rest are usually not supported, though sometimes you just need to change the name or value slightly to make it work.

 

 

 


@ActivityFix Thanks for the detailled explanation!


Just a note, maybe it comes without saying, but I’d be careful about undocumented features / fields. I mean, it works now, but it can stop working any time without warning.

(I’m working for a software company and it's not fun when a desperate customer reports a “bug” because their super important integration stopped working… only to find out that they had been using some unsupported functionality that got recently fixed. That can be a real mess.)

Not saying “don't do that”, and the insights and tricks shared by ​@ActivityFix are actually very cool, but since OP mentioned that this functionality is crucial for their app, I thought I should mention the above. So, perhaps if you do use this / rely on this feature, have a plan B if it suddenly stops working.