Possible Bearer Token API Bug

I'm running into this with a second device as well. Both of these devices are new to the market (and I'm under an NDA on both so I can't give you much information) Both of them are expecting extra information in the header either during request token validation or during the api calls.

I've ran through the source on your OAuth package and I see no way to add random headers during any of the calls. I have modified my callAPI method to allow additional headers and I'm going to have to modify the process area as well.

Or maybe I'm reading the code wrong?

It is a bit odd that you need to put that information in the content-type header. Anyway, you can use the RequestContentType parameter, as you may read in the documentation.

I am not sure if this is what you need because I do not have access to that API documentation. Just let me know if that does not solve the problem.

I have solved one of the two device problems.

They required the access token in the header to have a key of 'access_token' without the word 'bearer'.

Right now, your class sends 'Authorization: bearer [key]'.
I had to send 'access_token: [key]'.

I did not see a way in the current api to accomplish this so I modified the callAPI to have a way to send arbitrary headers as an additional parameter.

The second one requires a much more extensive set of header keys. I do not see how the content-type change alone can handle this.

I would recommend modifying all calls to have a way to send arbitrary headers.

Regards,
Nick

That is totally not compliant with OAuth standard.

Isn't it better to ask that API provider to make their API work in a compliant way with OAuth standards so all OAuth clients can work with it?

They are just giving a hard time to everybody that wants to use their API and it will eventually lead to their API not be used as much as they hoped.