Technically I have no problem with this, it builds nicely on the code that is already merged into Jetpack. What I'm concerned about is this: we are adding a new endpoint here, can't we instead use an existing /settings endpoint? This would be more RESTful in my opinion. And if we are creating a new endpoint, and you feel it's justified, can we at least call it something like jetpack/tracking?

EDIT I misunderstood the wpcom API endpoint vs the Jetpack site endpoints

We would have preferred to use the existing user/settings API, but it's on the wpcom v1 API, which does not have any Jetpack-based user auth capabilities built-in.

can we at least call it something like jetpack/tracking?

It's called jetpack-user-tracking right, now which I see as more descriptive, although I guess if you want it a bit more RESTful, we could do jetpack/user-tracking

@zinigor Thank you for the review, much appreciated :-)

What I'm concerned about is this: we are adding a new endpoint here, can't we instead use an existing /settings endpoint?

I see what you mean about the Jetpack /settings endpoint.

I used a separate endpoint out of concern for permissions. Currently, this endpoint is much more user-centric than /settings, and it can be accessed by both wpcom-connected users, and also by users who are not wpcom-connected.

In the case of a user not being connected to a WP.com account, we simply do not track them. That's a short-term solution. Having this separate endpoint affords us some leeway with respect to permissions -- in case a more long-term solution presents itself in the near future.

And if we are creating a new endpoint, and you feel it's justified, can we at least call it something like jetpack/tracking?

Good suggestion. How about /tracking/settings ?
Or, seeing as this is user-centric, how about /user/tracking/settings ?

Endpoint changed to /tracking/settings