Having trouble data types and API

This is the data type I am trying to convert to json:

This is the JSON I am receiving:

As you can see the “Segment” field is a list of segments, but the segments themselves are being shown as object Id’s.

Segments data type:

Is there any way to prevent this?
I would like the segment field in the json to be displayed like “Segment”: [
“Thermal Control”,
“Agriculture”,
“Database”
]

instead of: “Segment”: [
“1524163070040x586020356742665200”,
“1524163023934x467291017062962050”,
“1524162987394x555866570677608260”
]

Thanks in advance for any help!

Well, your API returns the segments as an array of numbers. Look at the response.

Those long number strings must be codes that represent business activities? What must be done is to map those codes back into human readable names. Is that a function of the API you’re using?

Alternatively perhaps that API has a flag you can set for “return the segments by description rather than codes”, if you get what I’m saying.

Looks like you are retrieving the Listing2s type of thing, and that those things have children things. Those children (like Segment) are returned with the unique_id of that thing. I think you have to do another call to the data api, but for each of the children, using the id provided in the Listing2s response. Haven’t spent much time searching using the data api, only inserting new records, but I don’t think there is a way to have it provide all the nested children values in one request.

Yep, you are probably right. Thanks for the help!

Oh geez. Didn’t realize this was the output of a BUBBLE APP API.

Wouldn’t an alternative (to the built in GET methods of the Data API) be to create a WORKFLOW API endpoint and then you can fully specify what gets sent in the response?

Seems a lot easier to do that in a case like this.

Ya, definitely an option. I suppose it depends on the project. For me, once the decision has been made to do something outside of Bubble, I build in Python. So once I’ve done that, I’d kinda prefer to keep as much there as possible and make it reusable. So spinning through the json and doing additional calls of the data api would give me a common way to gather bubble data, regardless of what was needed. But absolutely, a workflow endpoint is a great idea to throw into the list of options.

Yeah, it’s cool that there’s a “built-in”/automagic API in Bubble for Bubble apps but it doesn’t really feel that useful to me. Used it once (for communication with one of my own APIs).

Might need to use it again soon, but it’s kind of “why?” When you can just ping a workflow API and do anything.

Example: there’s an automatic endpoint for creating objects of x datatype. But you need to send EXACTLY the expected data values. If those values are better computed at the endpoint (or complex or unsupported — as is the case with date ranges) you’re better off defining a POST type workflow API.

So just do that ANYWAY. It’s easier.