Watson Personality Insights API -- Success (without binary file)

I struggled a bit to get an API connection working to Watson Personality Insights API, and saw that numerous users were struggling with similar issues in the forums – I couldn’t find answers here – so thought I’d give a working example of my API connector setup in case it helps anyone else. Here goes:

Tutorial for hooking into Watson Personality Insights (PI) API is here: IBM Cloud Docs

That covers the basics, which I won’t rehash here. From that point, I tested API connection in Postman, which I was able to do in about 3 minutes, even being new to Postman. Unfortunately, that didn’t translate well to connecting via Bubble. The biggest issue seemed to be that the Watson API instructions specifically call for the inclusion of a --data-binary FILE, which is not possible in Bubble, and IBM doesn’t provide clear instructions for how to work around this. After much trial and error and some digging, I finally found what seemed to work, which is to specify a second header --header "Accept: application/json". After I did that, then it all seemed to fall into place.

The screenshot above points out a few other smaller things, but the biggest gap was the binary file vs. json blob problem.

I should point out that 1) the above setup may not be ideal (I just know it works), and 2) I may yet run into additional problems that I haven’t seen yet, but at the moment I at least know I can make the call to Watson automatically at the push of a button in my app using a API connector plugin action workflow.

6 Likes

Great work. Could you provide a bit of insight into how you use Watson Personality Insights just for the sake of context more than anything?

Sure. The basic premise is that IBM has already trained a machine learning model to determine classic Jungian personality insights, needs, and values from a set of texts. This is a terrific leaping off point to build all sorts of potential applications without having to do this legwork yourself, and with the credibility (a.k.a. marketing/brainwashing) of “Watson” behind you. Try the demo to see the outputs.

Unfortunately as of right now, there doesn’t appear to be a solution to the --data-binary problem and hasn’t had any attention. Another post related to this is found below. Hopefully someone has something for this… I had to abandon that part of my project unfortunately.

Just posted on the other post, but have you tried using the following content type in the header for binary data?

“Content-Type: application/octet-stream”

Yes - Thank you for the post! However, the core of the issue is the way the information is encoded before it is sent. Bubble only sends it in “raw” rather than “binary” - So even though you tell it the Content Type, it just takes the binary data you send and does not encode it before sending out. Postman does this encoding for you when you click the “binary” circle as in the screenshot I posted. There is no way to choose a “binary” in Bubble - Unless I am mistaken (which believe me, I hope I am). If there was a way to choose that “binary” in Bubble for the encoding, this would all be solved.

Yeah, to be clear, I never “solved” the binary thing from Bubble. Turns out that Watson specifically can accept non-binary, they just didn’t document that very well.

It did/does seem odd that an API wouldn’t offer alternatives. It doesn’t really seem like a Bubble shortcoming per se.