(REMOVAL REVERTED)🚫 Removing Post Response Variables in v3 release

[sreelakshmi-bruno]

Important

We have decided to revert our decision and not to remove this feature :)

Overview

We are planning to remove Post Response Variables in the v3 release of Bruno.
This change aims to make variable management simple, intuitive, and predictable.

❓ What Are Post Response Variables?

Post Response Variables allow you to extract data from API responses and store them as variables using a declarative syntax.
They run automatically after the request completes but before post-response scripts execute.

💡 Why Are We Deprecating This Feature?

1. Confusing for Most Users

Most users prefer straightforward pre-request variables.
Having variables update after a request adds confusion about execution order and availability.

2. Breaks the Mental Model

Variables are generally to be set before a request runs, not after.
Post-response variables blur this logic, especially for new users.

3. Low Usage

We believe only a very small percentage of users employ this feature, yet its presence complicates the UI for everyone.

4. Alternative Approach Exist

Users who need to extract data from responses can use runtime variables in post-response scripts, which does the same thing

🔁 Alternative approach Guide

If you're currently using Post Response Variables, you can use the following alternative approach to get the same results.
Both approaches ultimately store values in runtime variables that can be used in later requests.

Before — Post Response Variables (UI)

After — Runtime Variables (Script)

Use the Script tab → Post Response section:

bru.setVar('method', res.body.args.method);

This produces the exact same result, as the post response vars table UI.

📅 Deprecation Timeline

• Nov 27 — In-app announcements and warnings
• Dec 15 — Removal of Post Response Variables & release of Bruno v3

[nikischin]

This is actually quite sad. I personally use post-response variables very often. It is very helpful to load sample data.

Lets say I have two requests:

getPosts

getPost/{sample.postId}

I would then have a post response variable in my getPosts requests like:
sample.postId = res.body.posts?.[0]?.id

And inside my getPost request I would have a pre-request script like this:

if(!bru.getVar("sample.postId")){
  await bru.runRequest("getPosts");
}

if(!bru.getVar("sample.postId")){
 bru.runner.skipRequest();
}

I understand, that the post response variables can be migrated to be included in the post response script, however, I prefer using the post response variables, since I see everything at a glance, just like I prefer using the assertions over the tests, whenever this is beneficial.

I however do not so much understand the use of the pre-request variables. I also do use them to provide information (just like request tags would) for the collection level pre-request scripts, however, this is a rather exotic use case. In most simple cases, there is no real benefit of using the pre-request variables over just hardcoding the value directly without the use of a variable. I would not want them to be removed either, however, I find them much more confusing, since they do stringify all values and do not allow the usage of booleans, integers, arrays or other native javascript data types.

[helloanoop]

Thanks for sharing feedback @nikischin .

I prefer using the post response variables, since I see everything at a glance, just like I prefer using the assertions over the tests, whenever this is beneficial.

To add additional context behind our decision to remove post response vars in v3 - we’re working on a formal schema for the entire collection you can preview an early draft here. While exploring this, we found that post-response variables introduce behavior that feels a bit too “magical” or unintuitive for many users. We’ll share a dedicated post about the schema itself and the broader vision around it soon.

All that said, there may be a better fundamental primitive that generealises this concept of post response variables. For instance an UI that allows to attach not just setVar, but setEnvVar or deleteVar etc pre-request or post response.

I find them much more confusing, since they do stringify all values and do not allow the usage of booleans, integers, arrays or other native javascript data types.

Supporting richer data types across all variable systems is something we absolutely want to improve, and the new schema is being designed with this in mind.

[VioletVolatile]

I however do not so much understand the use of the pre-request variables. I also do use them to provide information (just like request tags would) for the collection level pre-request scripts, however, this is a rather exotic use case. In most simple cases, there is no real benefit of using the pre-request variables over just hardcoding the value directly without the use of a variable.

The pre-request variable has been an absolute life saver for us. Bruno is mainly used by support staff and before we migrated to Bruno they would frequently mess up the JSON formatting, use the wrong quotes, not find the correct place to update (body, headers, auth), etc. This would result in a developer having to come in and help them fix the request or tell them where to find things.

Having a single place where all configurable variables are defined in an easy to use place is incredibly useful for non-technical people using Bruno.

[fantpmas]

Hmmm, not too happy either with this move. We heavily use post-response variables as they are very easy to add and consult using the UI.

[jccc-rde]

Are you going to provide a way to trigger (on/off) the Post response like the checkbox for Vars.
I found the post response var to be very convenient and easy to use compared to scripts.

[txg495]

Why not leave this functionality in place while you further develop your schema? We have hundreds of tests that run in sequence to test our CRUD level APIs. In the create response, we carry the unique identifier along to our other tests where we run validation tests as well as happy path tests. This will require quite a rewrite! I don't want to change them all to use script, then have a new and improved way of doing this come out later that will require a change once again.

I'm betting this chat becomes quite active once people fail to notice the breaking change and update! It seems like this feature would be used quite often.

[lengocthuong15]

I have use Post Response Var alot, and it is not confusing me at all. Moving Post Response var to Post response script is actually the same. This even harder to read a request in Bruno UI rather than show it in Post response var.

[Gpocas]

When I migrated from Postman to Bruno, the thing that impressed me most was how clean and simple Bruno's interface was, and the post-response-var functionality did this very well.

Compared to competitors, the post-response-var feature manages to be the simplest and most straightforward possible. I don't think this feature is difficult or breaks any mental model for users who use Bruno, and looking at other comments, it's clear that this feature isn't used as little as it seems.

I'm sad about this decision.

[gssj85]

It keeps getting worse and worse... I cannot use Bruno to debug anymore because it doesn't load javascript in the responses anymore now this.

If you guys are trying hard to make me find alternatives you are doing a good job.

[helloanoop]

@gssj85 can you create a GitHub issue for the JS issue you are facing in responses.

As for this discussion, we are monitoring it closely. V3 is not out yet.

[UberSurale]

That’s actually quite valid! I didn’t even know you could use post-response variables in vars tab at all, lol. I always set them in the post-response script because it’s clearer and gives you more control

[fabmoll]

3. Low Usage
We believe only a very small percentage of users employ this feature, yet its presence complicates the UI for everyone

Are you sure about that? For example, we have 5000+ request in our Bruno collection and for each we have post-response variable.

So we'll need to update all request to use the script now?

I hope that you'll propose something to automatically move the post response variable into the script. Without that I think it's a bad move on your side.

[helloanoop]

Hey everyone, Thanks for all of your feedback. We have decided to revert our decision and not to remove this feature :)

Also, I agree with the general feedback that this decision felt a bit rushed and not having a sort of "RFC" before such a huge change. We will do better.

Thanks again for voicing your feedback so passionately on this discussion.

[lengocthuong15]

thank you!!!

[fabmoll]

Thank you guys for listening and searching for the best solution!

[cdelaorden]

No one mentioned using post-response variables to save JWTs returned from login requests to be used in further calls, but for us it's the most useful feature. Glad you're not removing it for now.

[ryl]

I commend you guys for reconsidering and deciding to keep this feature.

I am one of those using post response vars heavily, and I found it to be a breath of fresh air compared to Insomnia (which I migrated from). I like using post response scripts as well, but I find that for simple cases where you want to pluck one thing out of a JSON response, the post response vars tab is just right for the job.

I think you guys made a great choice in keeping it. Thanks!

[tebruno99]

Thank you, this is a heavily used feature across all products and projects. To have to write a script for something as common as getting values from a response into variables would be a huge undertaking.

[BBE-91]

I just see the notification and was disappointed.
Then see this post, and happy to see the removal décision is reverted.
Thanks !