09-01-2020 12:58
09-01-2020 12:58
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.
09-16-2020 09:00
09-16-2020 09:00
Thanks for the side conversation @JohnFitbit .
Following up here, this was all a side effect of how the original subscriptions were set up:
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
09-02-2020 13:51
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 requires activity
body
collection requires weight
foods
collection requires nutrition
sleep
collection requires sleep
userRevokedAccess
collection has no scope requirementsactivity
, nutrition
, profile
, settings
, sleep
, weight
scopes are required.
09-02-2020 14:23
09-02-2020 14:23
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
09-02-2020 14:56
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
09-16-2020 09:00
Thanks for the side conversation @JohnFitbit .
Following up here, this was all a side effect of how the original subscriptions were set up:
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.