09-01-2020 12:58
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

09-01-2020 12:58
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
This issue occurred for me in a different OAuth app registered as a different user, but I have the same setup under this account and am expecting to encounter the same issue.
Since users are only allowed to subscribe to a single collection for a given feed, I have created three separate feeds for sleep, activity, and body. Each feed has the exact same URL, differing only in feed ID and which collection I use for subscribing. While testing, I have been able to see each different collection arrive via our webhooks, but when looking at the activity for each feed on Fitbit, only one of the feeds shows any activity. Moreover, this one feed shows activity for the other two collections.
Can you please explain why I am observing this behavior? Thank you.
Answered! Go to the Best Answer.

- Labels:
-
Subscriptions API
Accepted Solutions
09-16-2020 09:00
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

09-16-2020 09:00
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Thanks for the side conversation @JohnFitbit .
Following up here, this was all a side effect of how the original subscriptions were set up:
- A subscriber is the feed itself. This is what the developer creates in the app settings and the ID assigned by the developer here is the subscriber ID.
- A subscription is when a user registers to a subscriber. The subscription ID is some unique identifier used to associate some user with a particular subscriber and collection. This is not generated anywhere on Fitbit's side and is instead provided by the client issuing the subscription requests.
Since the subscription ID needs to be unique across collections for a given user and subscriber, my original thought was to have separate subscribers for each collection. Although each POST request to subscribe a user to a particular subscriber had a different subscription ID in the request URL, the subscriber ID was not present at all. This caused all user updates to be on the same subscriber, rather than each collection showing up on different subscribers.
In the end, it was a simple misunderstanding. The subscriber ID you pick when creating a subscriber should not be used as part of the request URL path. It should instead be added as a header or query param, as detailed on the Subscription API docs.

09-02-2020 13:51
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post



09-02-2020 13:51
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Hi @LifeOmic-Dev,
I just want to make sure I understand what you're encountering, so please correct me if I misunderstood.
Using the same subscriber url, you subscribed to 3 types of collections (sleep, activity, and body). However, you're only seeing webhook notifications for activity and not the other two? Can you also clarify what you mean by "looking at the activity for each feed on fitbit"?
The only thing that pops into mind at this time is to ensure that the appropriate scopes have been enabled during the consent process:
activities
collection requiresactivity
body
collection requiresweight
foods
collection requiresnutrition
sleep
collection requiressleep
userRevokedAccess
collection has no scope requirements- If no collection specified,
activity
,nutrition
,profile
,settings
,sleep
,weight
scopes are required.

09-02-2020 14:23
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

09-02-2020 14:23
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Not quite. I have one subscriber for activity, one for sleep, and one for body. Depending on the scopes granted by the user, I subscribe them to the respective subscriber(s). That should get around the issue you pointed out at the end.
On the "Edit Application" page, I have the option to view details (messages sent) for each feed. I can view the stats for all three, but only the subscriber I used for activity will show any messages. I'm also seeing it pick up messages for the other two.
I'm suspecting that the shared subscriber URL is what is causing them all to be collected on the first subscriber.

09-02-2020 14:56
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post



09-02-2020 14:56
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Thanks for clarifying @LifeOmic-Dev. I'll have someone on the team look over this with me.
Could you confirm that there is new data available for the body and sleep collections from the users you're subscribed to? Is this affecting all users or some users? Could you PM me a few user IDs that are subscribed to these collections?

09-16-2020 09:00
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

09-16-2020 09:00
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Thanks for the side conversation @JohnFitbit .
Following up here, this was all a side effect of how the original subscriptions were set up:
- A subscriber is the feed itself. This is what the developer creates in the app settings and the ID assigned by the developer here is the subscriber ID.
- A subscription is when a user registers to a subscriber. The subscription ID is some unique identifier used to associate some user with a particular subscriber and collection. This is not generated anywhere on Fitbit's side and is instead provided by the client issuing the subscription requests.
Since the subscription ID needs to be unique across collections for a given user and subscriber, my original thought was to have separate subscribers for each collection. Although each POST request to subscribe a user to a particular subscriber had a different subscription ID in the request URL, the subscriber ID was not present at all. This caused all user updates to be on the same subscriber, rather than each collection showing up on different subscribers.
In the end, it was a simple misunderstanding. The subscriber ID you pick when creating a subscriber should not be used as part of the request URL path. It should instead be added as a header or query param, as detailed on the Subscription API docs.

