Ok. In the interest of making the UI more approachable and less confusing - especially for new and/or nontechnical users - I strongly suggest rethinking the UI for specifying body content. Consider, for example, the following configuration for a POST request…
Guess what gets sent as the body. Absolutely nothing. It’s empty. Why? Because the two indicated regions represent entirely separate and distinct, and importantly, mutually exclusive ways of specifying the call’s request body. But the UI makes that about as clear as Missouri River water. (In case you’re wondering, the Missouri River in the US is nicknamed the “Big Muddy”.)
If the Queryst. option is enabled for the first three params, then the call gets sent as expected - i.e. 3 query params plus a JSON body with params 4, 5, and 6. Similarly, if the JSON content is deleted from the second input method, then the call gets sent as JSON with params 1, 2, and 3.
Basically, if there’s any body content defined in both sections, Bubble sends an empty body. But more importantly, it provides no feedback that anything is wrong. At a bare minimum, some red text should appear informing the user of the issue.
Each of the input methods has some advantages and disadvantages. The first is fine for flat JSON structures with simple string values. Bubble automatically formats the values as “JSON safe” - i.e. runs the values through JavaScript’s JSON.stringify() method before sending. The downside is that there’s no way to send more complex JSON structures or anything but string values, such as a numbers or booleans (true/false).
The second method is much more versatile and powerful. You can create nested JSON structures, including dynamic lists, as well as send non-string values. But of course, it takes more time to set up. (If you’re relatively new to the API Connector, you might benefit from this revelation I had a few years ago, after I’d already been using Bubble for several years.)
Anyway, this is one aspect of the UI that could benefit from a redesign.