Developers

[adamkaz]

All,
I have tried for a while to get a response from Roku - I'm hoping someone here can help with this one. I am trying to use the Roku push notifications. I am successfully receiving them, but I would like to acknowledge them and stop the same notification from coming over and over again.

From the documentation:
"When a qualifying event occurs, Roku attempts to send the notification every few seconds. If the notification is not successfully delivered within a reasonable time period, Roku removes it."

In reality, I am seeing that Roku attempts to send the notification every hour for a week. In the API, they talk about responding to the message and make a mention of some "security" they have implemented to prevent someone from "crashing the Roku system". It says to "The partner must return this (responseKey) and only this in the response content." later on, it says "Additionally, you are required to send an ApiKey header with the value containing your Roku API key". I have tried doing this. My response has a header with apikey-> (actual api key) and the response message is in JSON as {"responseKey":(actual response key)}.

Has anyone set this up successfully? What am I missing?

It also seems very insecure that Roku is requiring us to respond to a message with our API key in the header. Anybody could send a properly formatted message to the route we are listening on and get our API key back. I could whitelist the IP addresses, but there are a bunch that the notifications are coming from and Roku doesn't list them anywhere. I'm wondering if most people verify the transaction id with Roku before acknowledging the message. This seems like an unnecessary extra trip to the Roku server each time. My $0.02 - there should be an "acknowledge message" endpoint where you do a simple post to "/(actual API key)/(actual response key)" to acknowledge messages.

[EnTerr]

"adamkaz" wrote:
It says to "The partner must return this (responseKey) and only this in the response content." later on, it says "Additionally, you are required to send an ApiKey header with the value containing your Roku API key". I have tried doing this. My response has a header with apikey-> (actual api key) and the response message is in JSON as {"responseKey":(actual response key)}.

Sounds confusing!
My inclination by just reading that would be to do .AddHeader("X-Roku-Reserved-Dev-Id", "") instead and... don't know. It's baffling^. Maybe responseKey value bare in the body, no JSON?

(^) some parts of the docs make me wonder if RokuCo is running a secret recruiting program akin to Google Foobar. "Oh, you were able to use this API after all? You love a good challenge when you see one. You are my kind of people!"

[adamkaz]

I'm pretty well convinced that it is a social experiment.

[adamkaz]

Bumping this. For each of these I tried both headers of apikey->(actual API key) and partnerapikey->(actual api key)

Here is what I've tried and why:

1) Returning a JSON message with the response key: {"responseKey":(actual response key)}
2) Returning a plain text message with just the response key. Tried this because the documentation says "The partner must return this and only this in the response content"
3) Returning the whole message back. I tried this because the documentation says "Before downloading the content, Roku checks to ensure that the size is equal to the size of what was sent".

Unfortunately, none of these worked. Can we please get this explained and/or added to the documentation?

[ov2015]

Bump again....

I know it has been months since the last reply, has anyone got any replies.
I have tried all and have been posting in the forum but no one is replying.

Let me know if you guys have anything

[adamkaz]

I gave up. I'm just logging each notification and then checking new notifications against the existing ones. I also learned something interesting - for customers other than the developer, the customerID reported in the webhook push doesn't match the customerID when validating transactions.

So, in summary, to process a webhook push:
1) I check to make sure I haven't received it before
2) I validate the transaction with Roku to figure out the "true?" customer ID
3) I do what I was planning on doing with it

If we could get a hold of someone familiar with this codebase within Roku, that would be awesome. Steps 1 and 2 are an unnecessary waste of resources for both us and Roku. #1 should be easy to fix (they just need to document "accepting" webhooks better. #2 is a bug and likely a security issue. I am guessing that they are doing something to mask "real" customer IDs and it is not correctly implemented on the Roku push notifications.

[RomanKh]

Hello? maybe you find some solution from 2016 year. We have same problem 😞