Strava activity update webhook payload example

Strava · event: activity update (aspect_type: update) · content type: application/json

This is a representative sample — fake IDs, real structure. To see a payload with your data, point the provider at a capture URL (button below).

See it live, not frozen

One click creates a free capture bin with this exact payload already in it — pretty-printed, headers inspectable, replayable to your own endpoint:

Then paste the bin's URL into Strava's webhook settings to capture a real delivery. No signup.

Headers

content-type: application/json

Body

{
  "aspect_type": "update",
  "event_time": 1788148800,
  "object_id": 1360128428,
  "object_type": "activity",
  "owner_id": 134815,
  "subscription_id": 120475,
  "updates": {
    "title": "Sunday long run"
  }
}

Things that bite people

These events are completely unsigned — no signature header, no auth header, nothing. The verify_token you chose only ever appears in the subscription-validation GET, never on event deliveries. Treat the payload as a pointer: read object_id, then fetch the real object from the Strava API with your access token — the authenticated fetch is your integrity check.
object_type is always "activity" or "athlete"; aspect_type is always "create", "update" or "delete". For activity updates, updates keys can be "title", "type" and "private" — and private is the string "true" (visibility set to Only You) or "false" (Followers Only or Everyone), not a boolean. An athlete deauthorizing your app arrives as an athlete event with "updates": {"authorized": "false"}.
One save can fan out into several events. A single event may carry multiple updates keys, but some activity attributes update asynchronously — Strava's docs give the example of a type + title change where the type change lands in a separate, later event. Dedupe/merge on object_id, not per-event.
The visibility-flip trap: apps with activity:read scope (and not activity:read_all) never see private: "true" updates — an activity flipped to Only You reaches them as a delete event, and back as a create. Receiving privacy update events requires activity:read_all scope. Handle deletes as "stop showing this", not "the athlete removed it".
Respond 200 within two seconds; failed pushes get retried up to a total of three attempts, then the event is gone — process async. Full comparison in the retry-schedule table.
Before any of this arrives you must pass Strava's subscription-validation GET — a JSON {"hub.challenge": …} echo with a two-second deadline (not Meta's raw-text echo, despite identical query params). A bin passes it zero-code: Strava "callback url not verifiable".

Send it yourself

Reproduce this delivery against any endpoint (your handler, a bin, staging):

$ curl -X POST https://your-endpoint.example/hook \
  -H 'content-type: application/json' \
 -d '{"aspect_type":"update","event_time":1788148800,"object_id":1360128428,"object_type":"activity","owner_id":134815,"subscription_id":120475,"updates":{"title":"Sunday long run"}}'

← All payload examples · Related guide · Signature debugger · Docs