Bubble Json Formatting of API call requests

Would this be the appropriate way to deliminate the use of quotation marks?


I keep getting errors in my API call that says it is expecting a delimiter and error is JSON code and it only happens when I am sending in values that have quotation marks.

FYI, I am not sending in the values as \\\"goodies\\\", I am sending it through as “goodies” and Bubble translates that into \\\"goodies\\\"in much the same way they translate a line break as \\\\n\\\\n

I’m having a very difficult time with the API provider to resolve the issue as I feel it is on their side and not my side (AKA Bubble side).

When I send in the same exact content to the API call and I remove the quotation marks from “goodies” to read goodies, the API call works just fine, so the failure and message indicating it is related to expectating a delimiter and JSON code, doesn’t seem to be caused by the use of \\\\n\\\\n for line breaks but the use of \\\"goodies\\\" for “goodies” or any other word with quotation marks around them.

When I use https://jsonformatter.curiousconcept.com/ and paste in the error Body from the API call I get the following information about issues with the JSON.

So another question would be, is Bubble formatting that JSON for the API call which is provided in the API error Body or would that be something the API provider is doing?

This is how the API JSON body is setup in the API connector

and to reiterate the issue only happens when my input text contains quotation marks around a single word within the content.

@Jici any thoughts on the issue would be much appreciated or anybody else that knows about this stuff.

What is the full payload with the text? Can you send it to requestbin? Or just copy the text value

Unless I’m misunderstanding something, it should be as simple as using Bubble’s :formatted as JSON-safe operator. And since it automatically adds double quotes around the value, you don’t want them in API Connector Body field.

So something like…

    "input_text" : <input_text>

Thanks @sudsy

when I put after the dynamic expression the input text the operator :formatted as JSON-safe, I get the same error even after removing the quotation marks from the JSON body of the API connector.

Is there a way to see what the JSON-safe text actually contains? … And report it to Bubble support? … This operator may not be doing the complete job one wants it to do.

I have heard (not personally experienced) of instances in which JSON-safe cannot tackle some instances. In other words… the text may be presenting trouble to this operator.

I’m not sure. I am getting the same error without JSON safe operator, which is how I had been using it, and from suggestion attempted to use JSON safe operator, but still get same error.

All I can see is the error body which I save to my database using the result of api call error body so I can see what is being reported as an issue.

Thank you @Jici @sudsy and @cmarchan for your help.

The :formatted as JSON safe did in fact do the trick, I just didn’t take the approach correctly the first time.

I did alter the API connector API call by removing the double quotes around the dynamic parameter value in the JSON body the first time, the issue I did not address the first time was the fact that the call itself had both static text and dynamic text and I added the :formatted as JSON only to the dynamic text (as only can be done).

Based on the fact that all 3 of the respected community members were emphasizing the use of the :formatted as JSON safe, I took another swing at it, and this time in the workflow for the API call I used arbitrary text with :formatted as JSON safe and I put both the original static and dynamic text into the arbitrary text and it worked! Hooray!.

Thank you very much for all your help and input, I appreciate it.



All that operator does behind the scenes is make a call to the JavaScript JSON.stringify() function, which is used countless times across the web every day, so it should be quite robust.


This topic was automatically closed after 14 days. New replies are no longer allowed.