starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #4723] [bug]: Resolve and display global variable values within workspace environment variables #1763

New issue

Closed

opened 2026-03-16 21:38:54 +03:00 by kerem · 9 comments

kerem commented

2026-03-16 21:38:54 +03:00

Owner

Originally created by @iDschepe on GitHub (Feb 4, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4723

Originally assigned to: @nivedin on GitHub.

Is there an existing issue for this?

I have searched the existing issues

Summary

Description:
It would be highly beneficial if Hoppscotch supported nested variables, similar to how Postman handles them. This feature allows variables to reference other variables, making environment management more dynamic and flexible.

Expected Behavior:
Variables should be able to reference other variables using {{variable_name}}.
When evaluating a request, Hoppscotch should resolve nested variables recursively.
Nested variables should work in all applicable fields, including environment variables, request parameters, headers, and body content.

Use Case Example:

A user defines an environment variable:
base_url = https://api.example.com

Another variable references it:
users_endpoint = {{base_url}}/users

When making a request to <<users_endpoint>>, Hoppscotch should resolve it to:
https://api.example.com/users

For example, a team could define a global variable:
api_version: v1

Then, in an environment-specific setting, this could be reused dynamically:
api_base_url: https://api.example.com/<<api_version>>

Potential Implementation:

Enable recursive resolution of variables in requests.
Implement safeguards to prevent infinite loops (e.g., var_a = <<var_b>> and var_b = <<var_a>>).

Would this feature be possible to add? It would greatly improve variable handling and make Hoppscotch even more powerful for API testing.

Why should this be worked on?

Why is this useful?

Reduces duplication: Users don’t need to manually update values in multiple places.
With nested variables, global environment variables could be leveraged efficiently in different environments.
Enables dynamic configuration: Users can define base values and build other variables based on them.
Improves team efficiency: Teams can work with structured and reusable environment variables.

Originally created by @iDschepe on GitHub (Feb 4, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4723 Originally assigned to: @nivedin on GitHub. ### Is there an existing issue for this? - [x] I have searched the existing issues ### Summary **Description:** It would be highly beneficial if Hoppscotch supported nested variables, similar to how Postman handles them. This feature allows variables to reference other variables, making environment management more dynamic and flexible. **Expected Behavior:** Variables should be able to reference other variables using {{variable_name}}. When evaluating a request, Hoppscotch should resolve nested variables recursively. Nested variables should work in all applicable fields, including environment variables, request parameters, headers, and body content. **Use Case Example:** A user defines an environment variable: `base_url = https://api.example.com` Another variable references it: `users_endpoint = {{base_url}}/users` When making a request to <<users_endpoint>>, Hoppscotch should resolve it to: `https://api.example.com/users` OR For example, a team could define a global variable: `api_version: v1` Then, in an environment-specific setting, this could be reused dynamically: `api_base_url: https://api.example.com/<<api_version>>` **Potential Implementation:** - Enable recursive resolution of variables in requests. - Implement safeguards to prevent infinite loops (e.g., `var_a = <<var_b>>` and `var_b = <<var_a>>`). Would this feature be possible to add? It would greatly improve variable handling and make Hoppscotch even more powerful for API testing. ### Why should this be worked on? **Why is this useful?** - Reduces duplication: Users don’t need to manually update values in multiple places. - With nested variables, global environment variables could be leveraged efficiently in different environments. - Enables dynamic configuration: Users can define base values and build other variables based on them. - Improves team efficiency: Teams can work with structured and reusable environment variables.

kerem

2026-03-16 21:38:54 +03:00

closed this issue
added the
feature
label

kerem commented

2026-03-16 21:39:10 +03:00

Author

Owner

@liyasthomas commented on GitHub (Feb 5, 2025):

Nested variables are already possible. Please let me know if this is what you were expecting.

@liyasthomas commented on GitHub (Feb 5, 2025): Nested variables are already possible. Please let me know if this is what you were expecting. <img width="1470" alt="Image" src="https://github.com/user-attachments/assets/166d5f68-8fba-49d7-b9aa-fa2358eb7e7c" /> <img width="1470" alt="Image" src="https://github.com/user-attachments/assets/437f5ab2-df73-459c-9a77-df5a07fdce9c" />

kerem commented

2026-03-16 21:39:15 +03:00

Author

Owner

@iDschepe commented on GitHub (Feb 6, 2025):

Hi @liyasthomas,

Thank you for your quick response! That’s exactly what I was looking for.

Defined global var myGlobalVar

Tried to use ("nest") myGlobalVar variable from into an environment variable which was indicating red and showing a question mark.

Honestly, I didn’t expect it to work since my global variables weren’t being resolved in the environment variable edit dialog.
Would it be possible to resolve this somehow? This might also help future users before they have to restructure their environments. Is this functionality documented, and where can I find it?

Thanks again for your support!

@iDschepe commented on GitHub (Feb 6, 2025): Hi @liyasthomas, Thank you for your quick response! That’s exactly what I was looking for. 1) Defined global var `myGlobalVar` ![Image](https://github.com/user-attachments/assets/07166c33-aeb2-42b3-9b45-e8a0bee02730) 2) Tried to use ("nest") `myGlobalVar` variable from into an environment variable which was indicating red and showing a question mark. ![Image](https://github.com/user-attachments/assets/ecfe55ec-93e1-44de-b213-eb213fa315c5) Honestly, I didn’t expect it to work since my global variables weren’t being resolved in the environment variable edit dialog. Would it be possible to resolve this somehow? This might also help future users before they have to restructure their environments. Is this functionality documented, and where can I find it? Thanks again for your support!

kerem commented

2026-03-16 21:39:20 +03:00

Author

Owner

@liyasthomas commented on GitHub (Feb 6, 2025):

Have you selected the correct environment from the Environment Selector?

Here's my set-up:

Global environment with variable: myGlobalVar, value: hoppscotch.

My environment with variable: qwerty, value: www.<<myGlobalVar>>.io.

Make sure you've selected My environment from Environment Selector.

Expected nested environment value is inferred in the request setup.

@liyasthomas commented on GitHub (Feb 6, 2025): Have you selected the correct environment from the Environment Selector? Here's my set-up: 1. Global environment with variable: `myGlobalVar`, value: `hoppscotch`. <img width="1470" alt="Image" src="https://github.com/user-attachments/assets/ac909867-b45d-4534-9b36-2f1eb3e6159d" /> 2. My environment with variable: `qwerty`, value: `www.<<myGlobalVar>>.io`. <img width="1470" alt="Image" src="https://github.com/user-attachments/assets/f87fc4e1-4193-4024-bf62-1e2f779ae110" /> 3. Make sure you've selected My environment from Environment Selector. <img width="1470" alt="Image" src="https://github.com/user-attachments/assets/a66db478-c450-40ec-aae8-ef2d51b6ff61" /> 4. Expected nested environment value is inferred in the request setup. <img width="1470" alt="Image" src="https://github.com/user-attachments/assets/c9aa8ac2-aff6-41da-9c15-374f444bcebd" />

kerem commented

2026-03-16 21:39:26 +03:00

Author

Owner

@iDschepe commented on GitHub (Feb 10, 2025):

Hello @liyasthomas,

unfortunately, I didn’t have enough time to respond before this issue was closed. However, I was able to reproduce the behavior with the following steps:

I created a global variable named userRunner and assigned it a value.

I then attempted to reuse the variable <<userRunner>> within our workspace environment 01 Development.

It appears that the display issue is specifically related to workspace environments.

Environment 01 Development specifications:

Shared Workspace (Non-Personal Environment)
Workspace Environment

Best regards,
Mario

@iDschepe commented on GitHub (Feb 10, 2025): Hello @liyasthomas, unfortunately, I didn’t have enough time to respond before this issue was closed. However, I was able to reproduce the behavior with the following steps: 1. I created a global variable named `userRunner` and assigned it a value. ![Image](https://github.com/user-attachments/assets/3e5f875e-7566-447a-8372-f1d7176dcc44) 2. I then attempted to reuse the variable `<<userRunner>>` within our **workspace environment** `01 Development`. ![Image](https://github.com/user-attachments/assets/22a9d881-4ddf-4362-ad66-d25bf072d6fe) It appears that the display issue is specifically related to **workspace environments**. Environment `01 Development` specifications: - Shared Workspace (Non-Personal Environment) - Workspace Environment ![Image](https://github.com/user-attachments/assets/d5fdcd9c-511b-4355-80bb-38c8584ac575) Best regards, Mario

kerem commented

2026-03-16 21:39:31 +03:00

Author

Owner

@derN3rd commented on GitHub (Mar 30, 2025):

We are running into the same issue as well, but with secrets.

We are having multiple different staging envs and I want to create a global secret e.g. API_TOKEN_PROD that I can reuse in each workspace environment (Staging, Staging 2 etc) as secret API_TOKEN, so we don't need to create different requests for our envs with the different global secret name

@iDschepe did you find a workaround for this already?

@derN3rd commented on GitHub (Mar 30, 2025): We are running into the same issue as well, but with secrets. We are having multiple different staging envs and I want to create a global secret e.g. API_TOKEN_PROD that I can reuse in each workspace environment (Staging, Staging 2 etc) as secret `API_TOKEN`, so we don't need to create different requests for our envs with the different global secret name ![Image](https://github.com/user-attachments/assets/61a3229a-6124-4cc8-91f4-14c2fda70c07) ![Image](https://github.com/user-attachments/assets/190545eb-0d90-4559-b8fb-4b137a308082) @iDschepe did you find a workaround for this already?

kerem commented

2026-03-16 21:39:36 +03:00

Author

Owner

@iDschepe commented on GitHub (Apr 2, 2025):

@iDschepe did you find a workaround for this already?

Hi @derN3rd,

From what I understand, the "red warning" is just a display issue within the Workspace Environments.

We tested it ourselves: even if the variable — like API_TOKEN in your case — is shown in red, it should still be resolved correctly when used in a request.

So please go ahead and try using the API_TOKEN variable despite the red indicator — it should work as expected.

Looking forward to hearing whether it works for you!

@iDschepe commented on GitHub (Apr 2, 2025): > [@iDschepe](https://github.com/iDschepe) did you find a workaround for this already? Hi @derN3rd, From what I understand, the "red warning" is just a display issue within the Workspace Environments. We tested it ourselves: even if the variable — like `API_TOKEN` in your case — is shown in red, it should still be resolved correctly when used in a request. So please go ahead and try using the `API_TOKEN` variable despite the red indicator — it should work as expected. Looking forward to hearing whether it works for you!

kerem commented

2026-03-16 21:39:41 +03:00

Author

Owner

@derN3rd commented on GitHub (Apr 2, 2025):

From what I understand, the "red warning" is just a display issue within the Workspace Environments.

We tested it ourselves: even if the variable — like API_TOKEN in your case — is shown in red, it should still be resolved correctly when used in a request.

So please go ahead and try using the API_TOKEN variable despite the red indicator — it should work as expected.

Looking forward to hearing whether it works for you!

I see, it works when I just ignore the red warning :)

Thanks

@derN3rd commented on GitHub (Apr 2, 2025): > From what I understand, the "red warning" is just a display issue within the Workspace Environments. > > We tested it ourselves: even if the variable — like `API_TOKEN` in your case — is shown in red, it should still be resolved correctly when used in a request. > > So please go ahead and try using the `API_TOKEN` variable despite the red indicator — it should work as expected. > > Looking forward to hearing whether it works for you! I see, it works when I just ignore the red warning :) Thanks

kerem commented

2026-03-16 21:39:46 +03:00

Author

Owner

@AryaSvitkona commented on GitHub (Jun 20, 2025):

I observed the same issue for "nested" variables.

Version: 25.5.3
Type: Shared Environment with Team
App: WebApp & Chrome

Environment variables

Preview of the variable in the request tab

@AryaSvitkona commented on GitHub (Jun 20, 2025): I observed the same issue for "nested" variables. **Version:** 25.5.3 **Type:** Shared Environment with Team **App:** WebApp & Chrome ----- **Environment variables** ![Image](https://github.com/user-attachments/assets/6b3c554b-7d91-40ea-9b64-13ea8ab20e24) **Preview of the variable in the request tab** ![Image](https://github.com/user-attachments/assets/cf48efd1-f836-4cb7-ba79-a0060b95cbbb)

kerem commented

2026-03-16 21:39:51 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Jun 27, 2025):

Hi, closing this issue since it has been addressed in the latest release.

@jamesgeorge007 commented on GitHub (Jun 27, 2025): Hi, closing this issue since it has been addressed in the latest release.

kerem referenced this issue

2026-03-17 01:05:21 +03:00

[PR #1763] [CLOSED] Add the notranslate classes #3480