Activity-update webhook events coming Jan 15

[Zachary Isaacs]

Hi Developers,

TL;DR: Start filtering your Strava API webhook events by `aspect_type` by January 15, 2018.

The Strava API Team will release an upgraded activity-update webhook events system to all apps with a webhook events subscription on January 15, 2018; all existing subscriptions will be converted to the new system on that date. The new system will enable apps to receive webhook events when an activity has been created, deleted, or updated:

• Activity title change

• Activity type change

• Photos added/removed

• Activity privacy change, only for apps with a `view_private` access token

Here are examples of new and old payloads:

New payload:

{
 "subscription_id": "1",
 "owner_id": 321321,
 "object_id": 12312312312,
 "object_type": "activity",
 "aspect_type": "update",
 "event_time": 1297286541

 “updates”: {“activity_title”: “New activity title”}
}

Old payload:

{
 "subscription_id": "1",
 "owner_id": 321321,
 "object_id": 12312312312,
 "object_type": "activity",
 "aspect_type": "create",
 "event_time": 1297286541

}

If you're interested in beta testing the new webhooks system, please email devel...@strava.com and you will receive some more specific information about this process.

Between now and January 15, 2018, we will use this Google group and our developer website to communicate these webhook events changes. We will also reach out to all application owners in the next week via email.

We hope this change will satisfy your existing needs and give us the chance to extend support for subscriptions.

Best,

Zack

[Ryan Golbeck]

Awesome improvement!

Though the updates field is probably harder to represent, are there any plans to fire off update payloads if the user makes other edits (specifically if they crop a ride)?

--
You received this message because you are subscribed to the Google Groups "Strava API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to strava-api+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Minh Nguyen]

Awesome, I've been waiting for this for so long.
Thank you.

[David Sánchez]

Hello Zack

The current endpoint for webhook events will be availabe? Can we leave it without changes?

thanks

[Colin Duwe]

Awesome update. My app would benefit from a webhook update on Activity gear change.

Thanks

[Zachary Isaacs]

We don't have explicit plans to fire off webhook events for activity crops, but we'll certainly note suggestions that people would like to see in the future.

To unsubscribe from this group and stop receiving emails from it, send an email to strava-api+...@googlegroups.com.

[Zachary Isaacs]

You'll receive a POST request just like before -- the only difference is that instead of just receiving webhook events when an activity is created, you'll also receive webhook events when an activity has been updated (according to the attributes listed in my initial message) or deleted.

[Zachary Isaacs]

Noted!

[paha77]

Hi,

Will these weebhooks available for everyone or only for partner apps? (http://strava.github.io/api/partner/v3/events/)

Thank you,

[Yousef El-Dardiry]

Awesome stuff. Question re.: "Activity privacy change, only for apps with a `view_private` access token"

We still prefer not to ask for private permissions, but would love to be notified when a user changes an activity from private to public. Will this be supported with the new webhooks?

[Zachary Isaacs]

Great question. As you know, we highly recommend that apps request `public` access whenever possible. However, we also want apps with public access tokens to know when they no longer have access to an activity because it was made private. Thus, the behavior when an activity's privacy is toggled is such:

• If you have a `view_private` access token, you will receive that activity's new privacy setting in the `updates` field.
  
• If you have a `public` access token and not a `view_private` access token, and an activity is toggled from public to private, you will receive a `delete` webhook event for that activity.
• If you have a `public` access token and not a `view_private` access token, you will receive a `create` webhook event for that activity.
• If you have a both a `view_private` and a `public` access token, we will always display events that are appropriate for the `view_private` access token.

It's an interesting challenge to describe privacy events for apps with `public` access tokens; they should not know anything about private activities except that they do not have access to them.

Most importantly, from a developer standpoint, one perhaps unintuitive side effect is that you will have to build logic that can handle an activity being "created" and "deleted" multiple times if an athlete decides to repeatedly toggle that activity's privacy; this is obviously an edge case, but it is something that our current logic enables.

Let me know if you have any other questions.

[Zachary Isaacs]

No, webhooks are for everyone, and one of our longterm team goals is to get everyone to use them. We still ask that developers write in to request access so that we can check out the apps (and sometimes ask folks to comply with our Brand Guidelines); we like seeing what people are doing with our API.

[Hobson]

Hello Zachary,

In my opinion, algorithm of notifying about changes of 'private' flag for applications with only public access described by you is... um... unfortunate, to say at least ;) In my opinion main problem with it is that it is complicated, does not describe the change clearly, and even doing all of this, does not improve privacy handling in ANY way and wins nothing for anyone.

Having algorithm you described, we have an issue that 'Delete' and 'Create' events reported to applications with 'public' token do not reflect the reality. On the other hand, if change would be reported with "Updates" field just as in case of 'view_private', application would clearly know what happened, it would receive HTTP 401 from now on (thus privacy would be respected), and notification itself should not be considered the violation of privacy, because come on, one second ago I knew everything about the activity. So statement: "apps with `public` access tokens [...] should not know anything about private activities except that they do not have access to them." would still hold, because at the moment of receiving the notification I know everything about it anyway, application might choose to not 'forget' it, and it won't be able to retrieve it from now on. All these circumstances render the Create/Delete notifications to be just an obfuscation, and not actual means to ensure privacy. And implementation of such special handling adds additional work for you, devs. Lose/lose for everyone, really.

Maybe I am missing something in this picture, but that's my opinion.

Best Regards,

   Maciek

[Hobson]

Hello Zachary,

In my opinion, algorithm of notifying about changes of 'private' flag for applications with only public access described by you is... um... unfortunate, to say at least ;) In my opinion main problem with it is that it is complicated, does not describe the change clearly, and even doing all of this, does not improve privacy handling in ANY way and wins nothing for anyone.

Having algorithm you described, we have an issue that 'Delete' and 'Create' events reported to applications with 'public' token do not reflect the reality. On the other hand, if change would be reported with "Updates" field just as in case of 'view_private', application would clearly know what happened, it would receive HTTP 401 from now on (thus privacy would be respected), and notification itself should not be considered the violation of privacy, because come on, one second ago I knew everything about the activity. So statement: "apps with `public` access tokens [...] should not know anything about private activities except that they do not have access to them." would still hold, because at the moment of receiving the notification I know everything about it anyway, application might choose to not 'forget' it, and it won't be able to retrieve it from now on. All these circumstances render the Create/Delete notifications to be just an obfuscation, and not actual means to ensure privacy. And implementation of such special handling adds additional work for you, devs. Lose/lose for everyone, really.

Maybe I am missing something in this picture, but that's my opinion.

Best Regards,

   Maciek

W dniu czwartek, 30 listopada 2017 18:35:41 UTC+1 użytkownik Zachary Isaacs napisał:

[Zachary Isaacs]

Hi Maciek,

I'm up for discussing our privacy behavior. A couple of things:

1. Per our privacy policy (specifically bullet 5), apps must respect the privacy of activities and all associated data as they are set on Strava. We enforce our privacy policy strictly.
2. You're right about the inconsistency of saying an activity has been deleted and then returning a 401 on the API when you try to retrieve information about it. I'm filing a bug and will change the response to a 404. We already throw a 404 on the web when you try to view another athlete's private activity, so this update will make the API consistent with the rest of our product.

Our primary goal with the current implementation's privacy logic is to respect athlete privacy. If an athlete deletes an activity, we believe that apps with `public` access tokens should not know that the athlete has chosen to make that app private; apps should just know that they don't have access to that activity anymore.

I'm happy to keep the discussion going if you have more thoughts on it.

Best,

Zack

[Hobson]

Zachary,

Thank you for your response, as it makes a few things clearer. First please let me express that I am aware that whichever solution you (i.e. API devs) choose: 'set private is a change' vs 'set private is delete', an application must effectively (as per Terms of Service) perform the same steps: delete the activity, forget about it and never find out about it again. Whatever approach is chosen, there's really no big difference for application logic.

The potential problem I see is the API design and approach of expressing one action (change of the flag) in terms of another action (deleting an activity). I'd suspect that such handling will bite someone sooner or later and is more probable to cause consistency problems now  or in the future, as you'd have to stick to this pattern (delete vs change, and HTTP 401 vs 404 vs actual response) for many combinations of actions, requested entity types and access levels, now and in the future in endpoints that will potentially be added, and/or document it appropriately for every endpoint/notification.

I fully support your concerns about privacy and I agree that special care needs to be taken to avoid revealing information to unauthorized users, but still I fail to see how "delete" notification helps in discussed case:

 - When an application would receive notification that "activity changed to private", no private information leaks because application already has it. I can't see the advantage of "delete" notification in terms of privacy.

 - When application would receive HTTP 401 when accessing private activity, no private information leaks because no properties are returned, and there is no way to associate queried activity with any athlete. I can't see the advantage of HTTP 404 in terms of privacy.

As I see no advantage of 'faked' information over the 'real' one, I do not understand why choose non-trivial, 'obfuscated' approach (both in terms of implementation, and API contract) over straightforward and expressive one. Actually, I think that everything boils down to one simple question: https://i.imgflip.com/20aczv.jpg ;)

Having said all of that, I think that potential issues are more likely to hit API maintainers (Strava devs) rather than application developers. As there might be other factors I am missing or I am not aware of (business, legal, whatever), and (at least for now) it seems that whichever approach is chosen, applications would process both kinds of notifications in the same way, I do not think we need to dig into the topic any further. I just wanted to express my opinion.

Thanks for listening,

     Maciek

[Zachary Isaacs]

Hi Maciek,

Thanks again for bringing this up. It's sparked a lot of conversation internally about how we handle private activities.

Here's the case in my mind for returning a 401 vs a 404 for an activity which an app previously could access that has been made private:

• 401 lets apps know that the activity has been deleted.
• 404 does not let apps know that the activity has been deleted.

Throwing either error prevents an app from retrieving data it can't access, but the difference is the privacy of the privacy-change action itself. As you suggest, this type of nuance often leads to complex developer solutions, but we're willing to invest the time on this one. We also trust that our developer community will let us know when we're being inconsistent or are doing something wrong!

Best,

Zack

[Michael Wood]

Anyone have an example curl command to remove a subscription?  Thanks

On Wednesday, November 22, 2017 at 11:40:47 AM UTC-8, Zachary Isaacs wrote:

[Ryan Golbeck]

It looks like the list subscriptions return payload has changed too.  The object_type and aspect_type fields have been removed (before the January 15th date).  Is that part of the migration to enable the update activity events?