Repository navigation
Gear notes field (visible in Garmin Connect app) not exposed by get_gear()/gear-service endpoints #420
Description
Context
The Garmin Connect app lets you add a free-text "Notes" field on a piece
of gear (e.g. a pair of shoes) — separate from the "Make/Model" field
(customMakeModel, which the API does expose). After saving a note
through the app, get_gear() still returns the same fixed set of
fields:
gearPk, uuid, userProfilePk, gearMakeName, gearModelName, gearTypeName,
gearStatusName, displayName, customMakeModel, imageNameLarge,
imageNameMedium, imageNameSmall, dateBegin, dateEnd, maximumMeters,
notified, createDate, updateDate
No notes field — but updateDate does advance when the note is
edited in the app, confirming something is persisted server-side, just
not returned by this endpoint.
What I tried before opening this
get_gear()(list) and a direct GET on/gear-service/gear/{uuid}
(detail) — same 17-field payload both ways, no notes. Tried via both
the mobileconnectapipath andconnectwebproxy— identical.get_gear_stats()//userstats-service/gears/{uuid}— distance/
activity count only, nothing relevant.get_gear_defaults(),/gear-service/gear/types— nothing relevant.- A handful of guessed sub-paths (
/notes,/note,/comment,
/settings,/details,/history) off/gear-service/gear/{uuid}—
all 404. - The GraphQL endpoint used elsewhere in the library
(graphql-gateway/graphql): introspection is disabled, but probing
Queryfield names (gear,gears,userGear,gearList,shoes,
equipment,gearById,gearDetail,activity,user,notes)
all returnFieldUndefined, so gear doesn't seem reachable there
either. - As a last resort, a PUT to
/gear-service/gear/{uuid}with the
existing payload plus an added"notes"key (containing the exact
text I'd saved through the app) — accepted with 200,updateDate
advances, but the field is silently dropped: a follow-up GET has no
notesand every other field is byte-for-byte unchanged from before
the PUT.
Ask
Is the gear "Notes" field known to live under a different service/path
than gear-service (similar to how activity descriptions are a plain
field on the activity resource, set_activity_description)? If you
happen to know the right endpoint — or can point me at where the app
itself fetches it from — I'd be glad to test against my own account and
contribute a small get_gear_notes()/set_gear_notes() pair mirroring
set_activity_description.
Thanks again for maintaining this library — add_gear_to_activity()/
get_gear_stats() have been very useful for the shoe-mileage tracking
I'm building on top of it.
Activity
cyberjunky commentedon Sep 4, 2026
I don't know the endpoint/params yet, so yeah...
thomas-fouret commentedon Sep 10, 2026
Update: resolved for the write path, at least.
create_gear()(new in 0.3.13, #418/#424) accepts anotesfield in its payload, and I just confirmed on my own account that it does persist — created a test gear withnotes="...", and the text is visible in the Garmin Connect app under that gear's entry, not just echoed back in the creation response.So the gap I originally reported here seems to be specific to the read/update surface (
get_gear()and friends never returnnotes, and a PUT with anoteskey gets silently dropped, per my testing above) — the create-time write path goes through a different endpoint/payload shape that does persist it. Might be worth exposingnotesas a settable field on an eventualupdate_gear()too, if one gets added — happy to help verify against my account again if useful.Thanks again for the quick turnaround on #418!
cyberjunky commentedon Sep 18, 2026
Thanks for the update and the confirmation that
create_gear()'snotespersists!To implement
update_gear()(and figure out the read gap) properly, I'd rather work from a real captured request than guess at the endpoint/payload shape — same approach that gotcreate_gear()right the first time.If you're up for it, could you capture two things from your account:
gear-service/gear/v2/{uuid}, that'd confirm the shape mirrorscreate_gear()'s POST.notesfield? If so, what's the exact URL/path? That'd tell us whether there's already av2GET we could switchget_gear()-adjacent reads to, versus notes genuinely not being exposed anywhere on read.Feel free to redact anything unrelated (auth tokens, other account data) before pasting — just need the URL, method, and the JSON body/response shape.