Treat meals within a nutrition payload like samples, not ID-dependent records.
Treat meals within a nutrition payload like samples, not ID-dependent records. Each payload is a full-day snapshot keyed to the calendar date of metadata.start_time, so upsert (overwrite) the entire meals array per (user_id, date) on each receipt.
Why:
Each meal object carries id, timestamp (ISO 8601, microsecond precision), name, type, quantity and micros, but meal.id is not reliably stable across webhooks and some providers omit it, so do not rely on it as a universal key.
For incremental processing, key meals on a composite of timestamp + name + type, and hash the content to detect new/updated/unchanged/deleted entries.
Meals are populated per entry (with their own timestamps), including for Apple Health, so dedup on the per-meal fields rather than assuming a single daily blob.
For a historical backfill, large REST responses are split into chunks (at most 10MB or 10 objects per chunk, whichever hits first), all sharing one terra-reference header. To capture edits to past dates the polling cycle may miss, do an explicit GET /v2/nutrition pull for that date range.
Last updated
Was this helpful?
Was this helpful?
