Activities
Activities represent individual training sessions or races. Each activity belongs to an athlete and can have a nutrition prescription, selected products, and post-activity feedback attached.Activity lifecycle
- Create the activity with type, duration, and optional intensity/thermal stress
- Calculate a nutrition prescription for it
- Add products the athlete plans to use (optional — for preparation planning)
- Submit feedback after the activity (optional — improves future prescriptions)
Creating an activity
Activity fields
Multi-sport activities
For triathlons and brick workouts, specify sub-activities:Calculating a prescription
/v1/nutrition/calculate:
- Full tier (subscribed, covered, or in-trial athletes):
tier: "full"with the exactprescriptionobject (carb/sodium/fluid totals and per-hour rates), stored on the activity. Trial responses also carrytier_source: "trial",trial_ends_at, andtrial_calls_remaining_today— each calculation debits the trial’s daily call allowance, exactly like nutrition calculate. - Teaser tier:
tier: "teaser"with per-hour ranges (carb_range_g_per_hr,sodium_range_mg_per_hr,fluid_range_ml_per_hr), asubscription_ctawith the athlete’s subscribe link, and required attribution. Nothing is stored —GET .../prescriptionkeeps returning the last full-tier result, if any.
safety metadata is always included regardless of tier.
Getting a stored prescription
The
{prescription, safety} envelope is consistent across all Saturday endpoints that return prescription data. Always read prescription.* for values and safety.* for guardrail information. The not_instructions: true flag signals that these are recommendations for human consideration, not executable commands.Getting an activity with prescription
Listing activities
Submitting feedback
Post-activity feedback improves future prescriptions:Feedback fields
Activity type inference
If your platform has activity metadata but not a clean type, Saturday can infer it:POST /v1/infer/brick-types.