Keep your data in sync

The API has no webhooks and no "changed since" filter, so syncing means polling for what is new. The pattern below is reliable for new completed workouts.

Poll for new workoutsCopy Anchor Link

Completed workouts are sorted newest first and filtered by completedAt. Keep the largest completedAt you have stored, and on each run ask for everything from there.

1. Read your stored checkpoint, for example 2026-03-18T10:22:05.117Z. On the first run use the date you want to start from.
2. Call GET /workouts?from=<checkpoint>&limit=100 and page through the results with cursor.
3. Skip workouts whose id you already stored. from is inclusive, so the workout at the checkpoint comes back every time.
4. After all pages succeed, store the new maximum completedAt as your checkpoint.

Only move the checkpoint after every page was processed. A failure halfway then repeats work instead of losing it.

What polling does not seeCopy Anchor Link

• Edits to old workouts. If a coach corrects a workout from last month, its completedAt does not change, so a from filter will not return it again.
• Deleted data. Deleted workouts are simply no longer returned.

To pick up corrections, re-read a recent window on every run, for example the last 14 days, and update by id. For a full refresh, run an export periodically.

Push changes into VitruveCopy Anchor Link

If your system owns the roster, write it to Vitruve instead of re-entering it: create and update athletes, teams and coach assignments, exercises, load-velocity profiles and injury reports. Send every create with an Idempotency-Key derived from your own record, such as its id, so a retried create never makes a duplicate. See Writes.

How oftenCopy Anchor Link

Everything, reads and writes, counts against 30 requests per minute per key. Hourly or daily polling is typical. If you poll every few minutes, the list calls are small: a poll with nothing new costs one request.