Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multiple Subscription Feeds But Only One Shows Any Activity

ANSWERED

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.

Best Answer
0 Votes
1 BEST ANSWER

Accepted Solutions

Thanks for the side conversation @JohnFitbit .

 

Following up here, this was all a side effect of how the original subscriptions were set up:

  • 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.
  • 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.

View best answer in original post

Best Answer
0 Votes
4 REPLIES 4

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 requirements
  • If no collection specified, activity, nutrition, profile, settings, sleep, weight scopes are required.

 

Best Answer
0 Votes

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.

Best Answer
0 Votes

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?

 

Best Answer
0 Votes

Thanks for the side conversation @JohnFitbit .

 

Following up here, this was all a side effect of how the original subscriptions were set up:

  • 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.
  • 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.

Best Answer
0 Votes