Garmin Connect

**Quick judgement:** Technically solid local Garmin-to-Clawdbot bridge with good metric coverage and clear setup steps, but it relies on an unofficial API and insecure credential handling patterns that significantly lower its safety profile. **What it does well** - Syncs a useful set of Garmin data (steps, resting HR, calories, distance, intensity minutes, detailed sleep stages, and recent workouts) into a single local JSON cache. - Designed for continuous operation via cron every 5 minutes, so Clawdbot can work off fresh data without repeatedly calling Garmin in real time. - Provides straightforward Python helpers (`format_all`, `get_as_dict`) that make consumption from Clawdbot scripts easy. - Documentation is concrete and practical (install, one-time auth, test sync, cron setup, troubleshooting), which improves real-world usability. **Key risks and limitations** - **Credential security:** Setup instructs users to run `garmin-auth.py` with `email` and `password` on the command line. This can expose credentials via shell history, process lists, or logs, and is not aligned with best-practice OAuth flows. - **2FA guidance:** Recommending disabling 2FA or using app passwords weakens account security and is a serious downside for any account that might also protect sensitive personal/health data. - **Unofficial Garmin API:** The `garth`/unofficial Garmin Connect access is inherently brittle. Garmin can change or block endpoints at any time, impacting long-term reliability and potentially causing silent failures. - **Health data sensitivity:** Although stored locally, the cache file contains detailed activity and sleep data; environments with strict privacy/compliance requirements will need extra safeguards (file permissions, encryption, access control) that are not built in. - **Operational concerns:** Frequent polling (every 5 minutes) risks rate limiting or throttling if Garmin adjusts limits, and the skill does not appear to include robust backoff or error-handling strategies beyond basic troubleshooting. **Recommended scenarios** - Self-hosted, personal Clawdbot setups where the operator is comfortable with Python, cron, and managing local secrets securely. - Power users who want tight integration between Garmin metrics and custom automations or dashboards, and who accept the trade-offs of using an unofficial API. - Experimental or hobby projects where reliability and strict security compliance are less critical than flexibility and quick access to fitness data. **Not recommended for** - Security-sensitive or regulated environments (e.g., corporate wellness programs, clinical or research deployments) where storing credentials insecurely or weakening 2FA is unacceptable. - Non-technical users who might follow the readme literally without understanding the security implications of CLI password usage and 2FA changes. - Long-term production systems that require strong SLAs, given the reliance on an unofficial and change-prone Garmin interface.