Enable “raw body text” for Request Data feature!

Hi all,

Wanted to throw this out there for anyone who might not have seen it - seems to have been a very quiet update and I stumbled on it.

Bubble has enabled getting raw data from request data! For those of us who have to do things like generate hashes of incoming or outgoing API calls, this has been a huge time saver. :partying_face: :partying_face:

It’s also great for logging and debugging, instead of having to set up each field of an API response, you can now just dump the whole thing in a text field and get your full API call.

Thanks Bubble!

13 Likes

Came across that recently myself (and agree that it’s a cool idea) but I’m unable to get it to work with the response from a simple POST type “use as data” API call. Is there some trick to enabling that?

It seems like the call is made but whenever I reference ‘raw body’ property, it’s empty:

Run mode:

Anybody got any ideas here?

I got this message when I contacted them on Sept 22th regarding the raw body text being now exposed, but empty.

This is a feature I’ve been wanting so badly and that I’ve contacted them at the beginning of Sept to know if it was on their roadmap.

Guess we still need to wait…

1 Like

I was so excited to see it, but it’s truly not working

1 Like

Not sure if this helps, but all of my calls are set to include errors in response, as well as capture response headers.

Maybe enabling those will populate the raw body field as well?

5 Likes

Thanks for that info, @aiancu!

Can confirm that the setting “Include errors in response and allow workflow actions to continue” does indeed make the “raw body text” contain data. Lost half a day messing around with this!
This is a BUG and would take a dev 30sec to fix! There are some attribute assignment inside a condition instead of outside the condition!
FIX IT!

4 Likes

As a software dev, when I see stuff like this, it makes me want to show you our world for a day. lol. (INB4: “I am a dev”).

I get your frustration - I waste a lot of time on issues in Bubble too… but lowering the temp a bit works wonders when you need help. All caps and lots of exclamation marks just raise everyones blood pressures.

I assume you’ve already created a bug ticket?

1 Like

Well, I’m glad someone confirmed how this can be made to work. I think this isn’t so much a case of the feature being broken as it isn’t fully complete and it snuck into production. But it’s super useful and I hope it appears in fullly-functional form soon!

(Watch those commits, people!)

I am facing quite an issue to generate the signature according to Meta specs Webhooks - Messenger Platform - Documentation - Meta for Developers

Please note that we generate the signature using an escaped unicode version of the payload, with lowercase hex digits. If you just calculate against the decoded bytes, you will end up with a different signature. For example, the string äöå should be escaped to \u00e4\u00f6\u00e5.

Impossible to achieve using Only When workflow tests right?

1 Like

Why replying to me? Good luck with your things.

Do not like to reply like this, but since I am a developer with 40+ years of experience from SAP and Oracle DB, to building small sites from scratch with JS, I feel I have quite a good grasp of the field we are talking about. Bubble is just fun, and a play-pen in comparison.

One does not have to be a rocket scientist to get that when setting/unsetting an option, and something else breaks, and since the option condition should be unrelated, that there are some conditional statement that is faulty. Not 100% certain. Just 80%.

And regarding showing me the “world of an developer”, I ,as every other developer that produces stuff, works impossible hours to reach our goals and deadlines. My last effort were yesterday night, preparing for a demo next day. Think that was 18 hours straight.

And this BUG were responsible for ~6 of those hours. Would have liked to not have lost them…

BUG reported, yes. Frustration produces CAPS and !!! :smiley:

Best regards
Alexander

I hope this gets resolved for you :+1:

BTW I finally got around to trying the raw body response feature with an api call configured to capture headers and errors and can confirm that this makes raw body text populate. Cool.

I’m hoping that part of this as yet unfinished feature is that you could then use a raw body response as input to the api connector without having to literally execute a call to one’s own backend. (Which of course you can do, but wouldn’t that be cool to be able to rehydrate a raw body response back into a Bubble API response object right in the page… for those who don’t know, API response objects are a lot like Things, they’re an object with a couple of functions on it that are used to get their parameter values.)

1 Like

@keith any chance you’ve tried this with a nested API response? I’m struggling to return the raw body from a nested array via 3rd party API…

Example… my response includes some data items (a Person)

Nested within each Person, is a list of Employment Histories, with parameters for title, company name, etc.

I’m successfully saving each Person as a list of texts (which I’m then processing in a separate WF to create things in Bubble’s DB).

My issue is I should ALSO be able to save a list of the raw body text from each Employment History that’s nested underneath that Person. Once I have that, I’ll parse it through my own endpoint and return some values which I’ll save to to the originally saved Person I just created in Bubble’s DB.

But Bubble simply returns an empty value for each nested array Employment History. Nothing there!

Here’s a visual example of the response…

{

“people”: [
{
“name”: “Some Name”,
“email”: “some_name@name.com”,
“employment_history”: [
{
“title”: “Product Design”,
“organization_name”: “Some Company”,
},
{
“title”: “Senior UX Designer”,
“organization_name”: “Another Company”,
}
]
},
{
“name”: “Another Person”,
“email”: “another@person.com”,
“employment_history”: [
{
“title”: “VP Product Engineering”,
“organization_name”: “Some Biz”,
},
{
“title”: “Senior Engineer”,
“organization_name”: “Another Biz”,
}
]
}
]

}

Hey @jeffdbl - yeah, while objects in the API response do have a :each item’s raw body text operator, that operator does not function yet. (As Bubble has said, this feature is not fully baked yet.) As you know, you can see that those objects do have that operator (here I am inspecting it with my “Floppy Inspector” action:

But that expression – instead of resolving to a list of the raw body text – resolves to the list of nulls. My Floppy Inspector element logs the selected thing to the console and what we see is that there is a list object there (which should be a list of texts), but upon getting the list, the items are just nulls as shown in following snip:

So, that isn’t working properly yet. However, you can still know what it should be, just from the full JSON response. But yeah, you can’t get at it programmatically in vanilla Bubble yet.

You (or anyone else in this thread) might be sort of interested in the video I just posted about using my Floppy plugin with this API responses and I play around with the “raw body text” feature (but just at a macro level, not diving into retrieving rbt from sub-objects… thankfully, since that doesn’t work).

Here’s the video: Loom | Free Screen & Video Recording Software | Loom

1 Like

Thanks for the quick response! Good to know it’s not just me, and double good to know that the fix is likely in the works on Bubble’s end already…

For now, my sloppy hacky workaround is to stack multiple workflows where I specify the Item# of the parent thing (People) and Item# of the nested thing (Employment History). Since my results are paginated with a maximum result of 10 items returned per page, this is somewhat manageable – albeit with ~40 maximum combinations.

2 Likes

It’s a total coincidence that I happened to have just finished that video and had a project open that made that easy to test. I had actually inspected those sub-object’s :raw body text and noticed they were null but thought that was just something derpy I was doing… However, it’s clear that this part of the feature is simply not correctly implemented yet.

I’m trying to access the raw data from a webhook I receive just to save the JSON payloads for logging purposes. I can see the option to include headers but where is the option to include errors in the response?

I assume I’m missing something here…

Also, when I tick ‘include headers’ my endpoint starts failing the “only when” condition on every call, despite the webhook payload having the data it needs to pass the condition. Anyone know what’s happening?

The feature being discussed here is in the API Connector call setup. In your case if you want the raw payload, I think you can just say that this endpoint accepts text (not JSON). And then that text you receive is just the unparsed blob.