POST API Call - array inside of an array

Our issue is that we don’t know how to handle an array nested inside of an array.
I need to POST a body with the following structure:

Screenshot 2023-02-03 at 10.58.51

The issue is with the identification of the parameters. I should have the following parameters:

  • “person” - an array,
  • person’s parameters (name, lastname)
  • “items” - another array
  • item’s parameters (code)
    Instead I am getting this:

So the best I can do is this:

{ "person": [<List of person>] }

At this point, we build the whole JSON in the workflow and use a single dynamic parameter: <body>, but in such a form, I cannot set “allow optional” or “private” attributes for parameters.

Can someone assist me with that? Thank you

You can composte the Array when you call the API by doing :format as text from the list you are loading
Example
Let’s say I when to send an array of user data
The payload should be

{
	"Users": [{
		"name": "John Doe",
		"email": "john@doe.com"
	}, {
		"name": "Jane Doe",
		"email": "jane@doe.com"
	}]
}

So In Bubble this should be:

{
	"Users": [<user_list>]
}

In API Call I will set user_list parameters doing
Do a search for user:format as text
in format as text I will do

{"name":"this user name","email":"this user email"}

And the delimiter will be , (comma)
You can for format as text inside another format as text for nested array

3 Likes

Thanks @Jici but your answer is practically my answer:

{ "person": [<List of person>] }

you example is simpler, there is no nested array inside of a user.

The thing is, that with such approach, bubble will identify a single parameter user_list
so you cannot use Allow blank option for name or email

If there is no other option and we need to create the JSON via concatenation (in workflow, not the API connector) then a new error emerges.
Let’s say I have a form with list of people:

  • Name
  • Last name
  • Items - multiple items allowed

that I need to submit to the custom backend in a form for a JSON:

Screenshot 2023-02-03 at 10.58.51

If a user leaves the items or name or lastname empty, then I get a json like this:

Screenshot 2023-02-03 at 16.25.58

I can probably create a calculation to hide empty attributes but imagine you have 50 attributes in a JSON. Each attribute must be have a condition → IF lastname IS EMPTY THEN “” ELSE "lastname": <lastname> That’s a lot of work and a huge mess. That’s why you have the Allow blank checkbox for detected parameters, but I can not use it when JSON I created via concatenation and not inside of API connector’s endpoint.

“person”: [<person_info>]

Format as text works for nested objects too for example, the items array. Same thing as person just nested.

So you’ll use format as text on the original person, then inside of the format as text you’ll nest your items array with another format as text

Thanks, that’s a minor mistake on my end, not relevant to the issue.

You’re just not paying attention big dog. You come for help, but you want to be the only one who’s right. And because of that you can’t see the answer right in front of you.

last name is failing because there’s nothing there to empty out the object which would be “” and right now it’s just “lastname”:, but should be “lastname”: “”,

And for this to be setup properly you would want to use format as text.

so your api connector call would just be this line.
{
“person”: [<persons_array>]
}

and when you define what this persons_array variable is going to be, you’ll need to use format as text.

So it might look like Search for persons:format as text

Inside the format as text box will be {“name”:“This persons name”,“lastname”:“This persons lastname”,“items”:[Search for items:format as text]}

and setup the items array just like the persons array

1 Like

Yes this is complex. Allow blank work only if the API accept empty field (and most of them will accept null, not empty). More than that: number and boolean will mess up if you just activate allow blank in most case

@doug.burden I think I understand the idea, but with a very complex json - dozens of fields, multiple arrays - creating such a calculation is arduous. Every parameter needs to be “wrapped” inside of formatted as text.

I know that JSON fails because the parameter has no value. Adding the parameter only IF IT’S NOT EMPTY would solve the issue, right? But it seems like a messy solution.

I don’t think leaving an empty string is OK. With the PUT method, you clear some existing values on the backend. Also, in the case of a number, a server can reject your request due to a type mismatch.

lastname just needs to be nulled

if lastname is going to be empty it needs to read “lastname”: “” instead of “lastname”:

Sure, got it. Thanks. From what you and @Jici are saying I conclude that there is no better option and we need to create JSON via concatenation with some conditions to avoid empty parameters.

Thank you for all your help :bowing_man:

1 Like

It’s a JSON object that is expecting a string. IT HAS TO HAVE “” with or without a value

You are right but only if the attribute is a string and not a number. "" means an empty string. You can use 0 but it’s still a value. The only option is null but I’m not sure it will work inside of a bubble calculation.

If the JSON object is looking for a number value it will accept nothing, assuming the service you’re posting to expect an integer.

So “code”: , would work and “code”: “”, wouldn’t

Yes it will :wink:

1 Like

It will not work if this expect a number or boolean. You need to send null in most case
(“number”:1 … is not like “number”:“1”… like “test”:“null” is not the same thing for “text”:null)

Yes, I agree. “code”: , is an incorrect JSON syntax

1 Like

code is integer here. and true or false values from bubble will either be false or true and still should evaluate properly

We are not talking about true false in bubble, but in json. “accepted”:true for example.

1 Like

His issue is in Bubble.

Thanks for the tip. I hope that you find a solution that best fits your needs here.

format as text will solve your issues without needing any conditionals. But that’s just my 2 cents.