-
-
Notifications
You must be signed in to change notification settings - Fork 304
Description
Hi, and thank you for maintaining this library. It works very well for most Garmin Connect API operations.
I have a request related to activity uploads. The current upload_activity() method works, but it always uses a generic upload endpoint and a minimal multipart request. Garmin classifies these uploads as normal Garmin activities, which are then exported to Strava. This creates unwanted duplicates for projects that sync activities into Garmin from another source.
Tools like Peloton-to-Garmin avoid this issue. They seem to use an import-style upload path that returns a structured response, for example:
{
"detailedImportResult": {
"successes": [
{
"internalId": 987654321,
"externalId": "abc-123-def-456"
}
]
}
}Activities ingested this way appear to be treated as imported items, and Garmin does not forward them to Strava. The current upload method in this library does not allow selecting that path or setting the headers that some clients use.
Requested enhancement
Add an optional, more flexible upload mode that allows the following:
-
Use the Garmin import endpoint
/upload-service/upload/{fmt}where fmt is fit, tcx, or gpx. -
Allow optional headers (User-Agent, NK, Origin). These are used by Garmin Connect Mobile and some import tools.
-
Control the multipart request format, including the field name and content-type.
-
Optionally return the parsed JSON import response, including fields like internalId and externalId.
This would let callers use the library for upload cases that need Garmin to treat files as imported activities rather than device-like activities. It avoids duplicate creation in Strava without requiring everyone to reimplement custom HTTP calls.
I am happy to provide examples or help test the feature.