Endpoints for modern Garmin Connect Dashboard

[mattiacampana]

I've noticed that Garmin recently switched to a "modern" dashboard with different endpoints; e.g., https://connect.garmin.com/modern/pulse-ox/2024-06-05 is the new URL to access the pulse ox data for a specific date. Is this library able to handle this new URL format?

UPDATE: I've tried to download some data, but I'm receiving the following garth.exc.GarthHTTPError: Http Error: Error in request: 404 Client Error: Not Found for url: https://connectapi.garmin.com/wellness-service/wellness/daily/respiration/2024-05-17T00:00:00

by using the following garminconnect methods:

• garmin.get_sleep_data(date)
• garmin.get_stress_data(date)
• garmin.get_spo2_data(date)
• garmin.get_respiration_data(date)

while the following still work correctly:

• garmin.get_heart_rates(date)
• garmin.get_steps_data(date)
• garmin.get_daily_weigh_ins(date)
• garmin.get_stats(date)
• garmin.get_hrv_data(date)

[psdupvi]

I just checked api.get_sleep_data(date) and it worked fine for me:

{
  'dailySleepDTO': {'id': XYZ,
  'userProfilePK': XYZ,
  'calendarDate': '2024-06-06',
  'sleepTimeSeconds': 28260,
  # More fields...
  'bodyBatteryChange': 40,
  'restingHeartRate': 45
}

Every morning I call most of the endpoints (including every single one you're saying didn't work) to download data, and I did not have any issues recently

I believe what you're seeing is that the URL for the page itself has changed, but the underlying API calls have not changed. E.g., when you go to the Pulse Ox page at https://connect.garmin.com/modern/respiration/2024-06-05, you should still see a request go out to the underlying API page https://connect.garmin.com/wellness-service/wellness/daily/respiration/2024-06-05

In general, I do not believe we need to update the URLs to reflect this modern URL, since that's just the front end page, not the API which exposes the data

Can you be more specific about the precise code you're running to get those errors?

EDIT: I wonder if the issue is you're passing the full date and time, not just the date?

DOUBLE EDIT:

api.get_respiration_data('2024-06-05T00:00:00') returns the error GarthHTTPError: Error in request: 404 Client Error: Not Found for url: https://connectapi.garmin.com/wellness-service/wellness/daily/respiration/2024-06-05T00:00:00,

but

api.get_respiration_data('2024-06-05') runs just fine.

It's interesting that some of the other ones work -- I'm guessing Garmin does some parsing of the dates and times under the hood for those (since this project doesn't), but not for the others. E.g., get_heart_rates works with the time part for me

[cyberjunky]

@mattiacampana @psdupvi still woking here as well, so we have now 3 different types of endpoint, will they all cover all data we have now, or are the limitations to each of them?

[psdupvi]

I think there are just two types. The way I see it so far:

1. We have all the formats of the type {type}-service, like wellness-service or activity-service. These have a variety of different routes associated with them, and accept different parameters, but I'd group them all together. These make up all (?) of the endpoints the package currently supports.
2. We have some new graphql-gateway/graphql endpoints, where it looks like the endpoint is the same but the data sent with the request changes based on what you want back -- presumably with some defined GraphQL query structure.

We'd need to do some investigation about the GraphQL endpoints to determine if they have an additional data over the current service endpoints, although it might be a good idea to try to support those anyway -- it wouldn't surprise me if Garmin tries to fully switch over to GraphQL.

I think the confusion in this issue is that some of the service endpoints accept datetimes with hours, minutes, and seconds, whereas others only accept dates (no time component). In general, no changes need to be made to continue to support the package related to anything in this issue, since it's just a format issue with the provided parameter.

Maye there's an argument that the package should return a helpful error if the provided date includes a time component, or better documentation on the format (although get_respiration_data, for example, does say specify the date format in the docstring, and I think they all do). But that's a nice to have, in my opinion, since we do already say the kind of parameters you should provide.

In terms of supporting the GraphQL endpoints, I created #210 but haven't been able to investigate yet. I will at some point unless someone else gets to it first