Roku Developer Program

[adamkaz1]

This is a heads up to anyone relying on Roku billing push notifications.  We use these to track which users have cancelled and which recurring subscriptions have renewed, such that we can appropriately provide content to them.  Apparently on July 19 (while I was out on extended leave), Roku added a checkbox to the website on this page: https://developer.roku.com/api/settings titled "Stop sending billing notifications".  The default is set to checked, so we stopped receiving them.  Until I figured this out today.

It seems to me that if a developer had put a URL in that box, Roku should have been able to guess that we wanted to keep the notifications coming.

The result of this is that we will now need to make a large number of requests against our user base through the Roku API to verify that accounts were not modified during this period.

PS.  I had to generate a new account because I was not able to log in to the forum with my old account.  Even after password resets, etc.

[EnTerr]

FWIW, the checkbox is not checked by default for me. I also do not use that API, so wouldn't know if something changed (did they default set it completely reversed?)
Whoa, another embarrassment for the 10-thumbed RokuCo web engineers?

PM @RokuShawnS re your old account login. This shouldn't be happening even with this "Siberia in Winter" theme. But there is a "cooky" issue some have. 

[renojim]

I was one that had that "cooky" issue, but it went away on its own.  That box isn't checked for me either, but I also don't use push notifications.  Perhaps they checked it by default for those who do have a URL entered.

I'm just wondering why the push notifications are needed.  Can't you get subscription information from roChannelStore?  I figure I'm missing the use case for needing push notifications; multiple non-Roku devices linked to the same account maybe?

-JT

[adamkaz1]

We need to be able to verify account status for other platforms (android, iPhone, web, etc).

[renojim]

Thanks!  That's what I figured.  So a user is able to initiate a subscription or purchase on Android, for example, and still have it honored on Roku, right?  The requirement to use Roku billing doesn't interfere with this I would hope.

-JT

[EnTerr]

"renojim" wrote:
  Perhaps they checked it by default for those who do have a URL entered.

Well that would be exactly the opposite to "the right thing" to do... now wouldn't it!

Why even having a checkbox, i wonder? Not a great UI. It's like installing safety-lock on a hair brush/comb. Yes you could... but why?

Unless! Could it be that it gets auto-engaged when certain number of connection failures occur per time period? That will start making sense. Albeit still questionable (what kind of failures, how many in what period), it might be trying to ease on servers trying to push notifications to grossly wrong URLs.

[RokuJoel]

This checkbox is checked if your endpoint gets blacklisted for not responding to push notifications. After 10 days and 100 push messages failed (at least that is how it is supposed to work) there will be an automatic blacklist.

Some people have been affected without seeing the checkbox because they are sharing the endpoint with other channels - the same endpoint was configured in multiple accounts, but only one account showed the blacklist checkbox, and the other channels using that endpoint were not getting push notifications.

There is no notification at present to anyone, including anyone inside Roku that an endpoint has been blacklisted. There is a fix for that in the works.

- Joel

[adamkaz1]

Joel,

Thanks for the heads up, this would be awesome to document!!

I struggled to get push notification "acceptance" to work and eventually gave up, and only process webhooks if I have not seen them before. See - "Accepting Push Notifications".

Updating the confusing SDK language (The partner must return this and only this in the response content. Before downloading the content, Roku checks to ensure that the size is equal to the size of what was sent.???? How can the size be the same if I'm only returning a portion of the content????) and/or providing better examples of how to respond to webhooks would probably go a long way to alleviate this issue.

Perhaps some of the issues with this have been worked out on Roku's side. I'll attempt accepting them again.

FYI, I've been doing this for months, with over 11486 webhooks handled before this was turned off for me.