Zepp API integration

No. That is the point of the integration. We hold the Zepp Open Platform registration, the client credentials and the redirect URI; you call POST /v1/connect with your own id for your own user and redirect their browser to the URL that comes back. There is no Zepp secret in your environment, no callback route in your router, and no approval queue between you and your first connected athlete.

Two weeks free, then from 32.50 € a month billed annually — or 39 € a month with no year to commit to — for the whole API, every provider and every endpoint, with no per-athlete metering. Plans differ on one thing: how many of your users may connect a watch. Hacker is 250, for a project and its first users; Startup covers up to 5,000 of them; Scale up to 250,000; Enterprise removes the ceiling; and none of them meters calls, activities or endpoints. The usual price for a unified wearable API starts in the hundreds of dollars a month and charges again for each connected user, which is a pricing model that punishes exactly the thing you are trying to do. There is a 30-day money-back guarantee on any charge, and cancelling is a button in the Stripe billing portal; access ends when the period does.

You get push, not polling. When an athlete finishes a workout, Zepp notifies us and we send you an activity.created delivery — sealed to your public key as a JWE and signed with a detached JWS you verify against our published JWKS. Latency is whatever Zepp takes to process the upload from the watch, which is theirs to own and typically a matter of minutes. You never write a polling loop and never hold a rate-limit budget.

There is no API key anywhere in this, in either direction. You authenticate to us with an Ed25519 signature over the request itself — RFC 9421 HTTP Message Signatures — using a private key that never leaves your machine, so there is no bearer token sitting in a log line, a CI variable or a backup. And we never hand you the provider's own credentials either.

No, and the difference is the reason this page exists. Zepp OS is a JavaScript framework for building watch faces and mini-apps that run on the device — it cannot read a user’s workout from your server, because it does not have a server. This integration uses the Zepp Open Platform: server-side OAuth, and a webhook that delivers a FIT file per finished workout. If you have been reading @zos/ documentation and wondering where the activities endpoint is, there isn’t one.

All of them, because the integration is with the Zepp account rather than with a watch. Anything that syncs into a user’s Zepp app reaches you — T-Rex, Cheetah, GTR, GTS, Balance, Bip — and a model released next year works on the day it ships without a change on either side.

Yes — about 90 days of it. Zepp’s backfill endpoint replays past workouts into the same webhook that carries live ones, so they reach you as ordinary activities with no second code path on your side. The one caveat is timing: Zepp rate-limits backfill across an entire application rather than per athlete, so if you connect a large batch of users at once their history fills in over the following hours instead of at the moment they consent. New workouts are never delayed by this.

Yes — sleep, and sleep is the whole of it today. A night arrives as a `wellness.created` event with duration, the deep, light, REM and awake splits, Zepp’s own sleep score and the per-stage timeline behind `series_url`, on exactly the same terms and in exactly the same shape as a Garmin night. That is not a coincidence we engineered around: Zepp’s health API mirrors Garmin’s field for field, so if you already handle Garmin wellness you handle this with no branch. What you do not get is daily summaries — steps, calories, resting heart rate — because Zepp’s health push does not carry them. It does carry overnight HRV, which we acknowledge but do not yet publish: Zepp documents no schema for it and we will not put a resting-HRV number in front of your users that nobody has verified.