Per-request Variables

[gschier]

Overview

A common use-case for Insomnia is to define a set of requests up front, then only edit a small subset of values afterward (resource IDs, URL path segments, tokens, etc). This can be quite cumbersome if you need to frequently change a value inside a deep JSON structure, for example.

Solution 1 – Using placeholders

Placeholders could be defined in a request and Insomnia could detect these and provide an easy key-value editor to change/update them.

This could be done with a custom Nunjucks tag like {% placeholder "my name" %}, or maybe show an input for all variables that aren't defined in the currently active environment.

Solution N

your idea here

[bkonia]

I agree, this would be very useful. I'd like to be able to enter placeholders in the query parameters. When you submit a request, if the parameters have placeholders, it should automatically display a dialog for the user to input the values for the specific request. This would be much more elegant than manually editing the values in the query fields each time you submit a request.

[bkonia]

Another example of how this would be useful...

I'm working with a URL format in which the just the parameter value is appended to the URL, without the parameter name. For instance:

https://www.xzy.com/path/to/api/123

Presently, there's no way to automatically build this format in the query tab. I can manually insert a placeholder in the URL, but then I'd have to manually edit the environment each time I want to use a different value. If we had the ability to create per-request variables, then I could insert the placeholder in the URL and it would prompt me for the value each time I submit the request.

[bkonia]

So after reflecting on this a bit more, I'm thinking these placeholders should insert raw values, exactly as entered by the user, not a key/value input like in the Query tab. That would give us the flexibility to enter formats like the one I described, without Insomnia messing it up by trying to turn it into a standard query string key/value pair.

Another approach would be to allow the user to select the format on a per-line basis in the Query tab and also in this new per-request tab I'm proposing. You could have a little toggle switch next to each item, to allow the user to select whether the variable will be inserted in raw format or in key/value format.

[mgraham]

Definitely it should not be limited to query string key/value pairs.

@bkonia, if I'm understanding you correctly, you would want something like this:

https://www.xzy.com/path/to/api/{% placeholder "my name" %}

And then in the "placeholders" tab there would be a list of key/value pairs:

my name:  123

This would work for me.

However since I would frequently want to edit both query parameters and placeholders for the same request, it would be nice to have them both on the same tab, maybe in a split screen.

[bkonia]

Yeah, that's correct.

[mgraham]

Here's a wacky idea: how about being able to switch between sets of parameters and query key/value pairs for a single request? Maybe even keep a history of them?

[sylvainpolletvillard]

I was also looking for something like the Query tab, but for Path parameters.
Currently I use nested properties in environment variables as a workaround, but having per-request variables would be much better.

[ybadragon]

I agree, per-request variables would be great. We generate all of our services on the fly and because of that we needed a way of testing those calls so we created a generator for Insomnia as well that generates all of the requests. We seperate our requests by service and we currently store all of the variables for all of the requests in the environment overrides on a folder level but we would really like to be able to use different values for each of the calls even if they happen to have the same name for parameters. Screenshots below for visual on our setup.

Folder Seperation

Environment Variables (For Report Service)

[yevheniisemenov]

Definitely great feature! It would be good to have it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[axelfran]

Thumbs up for this feature. Would be much appreciated.

[eheaton]

Thumbs up for this feature as well. Would love to have this.

[ajitid]

Chimed in so that stale bot won't mark this as stale again.

[rburnham52]

I'd like to see an window of key value pairs for all the variables used in the request including this new concept of pre-request variables. This would give you the option to override any variable for the request but reset when you are done with the session.

[zealsprince]

As already stated in this thread, having a dialog window open when the request is made to fill out any placeholder variables would be a much appreciated feature!

Another idea would be to have these variables stored in a tab on the request much like headers and other fields to avoid opening the dialog every new request. In that sense the user only has to interact if they are missing.

Right now as a workaround I am grouping requests that use shared variables in a folder and having the folder contain shared variables as environment variables. This has the downside that every request shares the same variable while for some I would like to change that value each request (such as modifying an entry by an ID). Having the possibility to change that value when I am making the request would speed things up a lot and add a lot of flexibility to how you can structure your Insomnia workflow!

[Pulsahr]

Hello there,
I was about to move my team to Insomnia but the lack of this feature just stopped everyone. I see it was considered to be prioritized 3 months ago. Any news about this?

[ts14ic]

Chiming in.
As another temporary workaround, I've also written this plugin for myself:

UPDATE: Now published https://insomnia.rest/plugins/insomnia-plugin-path-parameter-tag

const pathParameterTag = {
    name: "pathParam",
    displayName: "Path parameter",
    liveDisplayName(args) {
      const name = args[0].value;
      return name ? name : args[1].value;
    },
    description: "replace part of URI path with given value",
    args: [
      {
        displayName: "Display name",
        description: "Optional name to display instead of value in Insomnia UI. Doesn't affect the request made.",
        type: "string"
      }, {
        displayName: "Value",
        description: "Value of the path parameter",
        type: "string"
      }, {
        displayName: "Description",
        description: "Optional description of this parameter, which doesn't affect the request made",
        type: "string"
      }, {
        displayName: "URI Encode",
        description: "Select to URI encode the parameter",
        type: "boolean",
        defaultValue: true
      }
    ],
    async run(context, name, value, description, mustEncode) {
      return mustEncode ? encodeURIComponent(value) : value;
    }
};

module.exports.templateTags = [pathParameterTag];

Compared to the popular path-parameters plugin, this:

• has the benefit of proper CURL
• and proper URI preview
• has the disadvantage of lacking a bulk editor
• you can't just type :paramName inside the URI, you have to ctrl+space and choose "Path parameter"
• and "URI encode" thing seems to be ignored during request time for me.

Both have the disadvantage of not being something, that an Open API import would put a placeholder for.

p.s. some screenshots
Looks like this:

Or if you set the "Display name"

The curl is correct

And this is opens on tag click (nothing unexpected)

[danshapir]

Chiming in.
As another temporary workaround, I've also written this plugin for myself:

const pathParameterTag = {
    name: "pathParam",
    displayName: "Path parameter",
    liveDisplayName(args) {
      const name = args[0].value;
      return name ? name : args[1].value;
    },
    description: "replace part of URI path with given value",
    args: [
      {
        displayName: "Display name",
        description: "Optional name to display instead of value in Insomnia UI. Doesn't affect the request made.",
        type: "string"
      }, {
        displayName: "Value",
        description: "Value of the path parameter",
        type: "string"
      }, {
        displayName: "Description",
        description: "Optional description of this parameter, which doesn't affect the request made",
        type: "string"
      }, {
        displayName: "URI Encode",
        description: "Select to URI encode the parameter",
        type: "boolean",
        defaultValue: true
      }
    ],
    async run(context, name, value, description, mustEncode) {
      return mustEncode ? encodeURIComponent(value) : value;
    }
};

module.exports.templateTags = [pathParameterTag];

Compared to the popular path-parameters plugin, this:

• has the benefit of proper CURL
• and proper URI preview
• has the disadvantage of lacking a bulk editor
• you can't just type :paramName inside the URI, you have to ctrl+space and choose "Path parameter"
• and "URI encode" thing seems to be ignored during request time for me.

Both have the disadvantage of not being something, that an Open API import would put a placeholder for.

p.s. some screenshots
Looks like this:

Or if you set the "Display name"

The curl is correct

And this is opens on tag click (nothing unexpected)

How can I use your plugin?

[Vap0r1ze]

Interesting use of the quote reply feature

[ts14ic]

Try Menu Bar > Application > Preferences > Plugins > Enter "insomnia-plugin-path-parameter-tag" > Install plugin

https://insomnia.rest/plugins/insomnia-plugin-path-parameter-tag

[ts14ic]

In addition, I imported a collection from postman, which had a lot of path parameters.
The values were lost, but at least I found a way to transform all of them into this tag (in all workspaces):

1. Close Insomnia
2. Open {insomnia config folder}/insomnia.Request.db (see this for folder location: https://docs.insomnia.rest/insomnia/application-data)
3. Do a regex replace: from (?<=/)(:\w+) to {% pathParam '$1', '', '', true %} (this replaces anything that looks like /:param to become /{% pathParam ':param', '', '', true %}
4. Save the file, open Insomnia

To replace in only one document, the document has to be exported first, probably, and the op should be done on the export data only, then reimported.

[zaverden]

cool solution, thank you for sharing

[mxmlnglt]

Hello, is this discussion stil active?

I remember regularly coming across this concept of "Path or URI Template" what seems to have been normalized a while ago; please check: https://en.wikipedia.org/wiki/URI_Template

Cheers.

[ts14ic]

I guess, since gschier is no longer maintaining the project, it's up to the community to resolve the issue. Just waiting won't help :).
This discussion only has 5 upvotes, including mine, while there are a LOT of interested people, since this discussion drags on from the time it was an issue about path parameters only.
So, at least upvoting the issue would be an indicator for Kong, about how important this feature is.
If somebody comes with a working PR, merging it would be a no-brainer then... IF everybody agreed on what they want.
And so far we don't have a consensus for what we want. Here is my opinion to add to the discord.

Per-request variables are redundant and not the right solution for path parameters:

1. How Open API specs look like is irrelevant.
   It's just a coincidence, that path parameters in Open API spec and variables in Insomnia use the same syntax of {} brackets.
   During code generation, or an import from an OpenAPI spec, Insomnia can replace whatever {paramName} it meets with :paramName.
   The reason why OpenAPI path parameters are currently recognized as variables, is because Insomnia does no such replacements.
2. Path parameters do not behave like variables.
   1. The UI mock (which most people seem to like) shows a key-value editor similar to query params.
      In it, the values of path parameters are flat scalars - integers, strings.
      Variables are not restricted to scalars, and can be entire objects.
   2. Defining variables is a chore.
      Currently, to define variables, you have to manually edit JSONs (and again, in JSON nobody is restricting you to define scalars only).
      And you have to define them with the same name as the placeholders.
      I think it would be more comfortable, if the UI auto-generates inputs for path parameters, based on the placeholders automatically (like Postman does).
   3. Path parameters cannot be empty. At least in Open API.
      So, in the case of path parameters, the UI input must also be static, without an option to "skip/disable" it.
      Something that is only relevant for path parameters, but not for any other variable.
   4. Path parameters must be URI encoded. Or maybe it should be an option.
      Insomnia doesn't provide any UI to arbitrarily encode the value of a "variable". No UX-friendly way to mark a value in JSON, to be URI encoded.
      But there could be for path parameters.
3. "Per request" variables are redundant. We already have the "per-request" editor right in front of us.
   Want a per-request header? Just type its value in the header pane.
   Want a per-request URI param? Just type it in the query pane.
   Want a per-request body? Type it in the body pane.
   And so on.
   Have a global template tag, that references a variable, and want to override that variable? Put the tag in the request, and reference a literal value then. This seems to be the only case, where per-request variables seem useful.
4. And finally, everybody would benefit, if the format is :paramName
   It's easier to type.
   It doesn't conflict with variable syntax.
   And most importantly, it's how Postman works. And we want what Postman does, even if we don't need Postman. A lot of people are trying to migrate from Postman, and it's unpleasant that all path parameters are lost during an import from Postman.
   If Insomnia would use the same format, fixing the import code would be super straightforward.

With all of that being said, I think it would make sense polishing @Vap0r1ze's PR and going with it.

Edit: tried to cut down the rambling a bit. More later :D

[mpern]

@wdawson ☝️

[damascene]

Any update on this?
@gschier I'm unable to get your plugin to work. Is it still working with recent version of the software? 2022.2
@ts14ic Your plugin seems working fine as a work around

[jkmartindale]

insomnia-plugin-path-parameters works just fine for me (even on 2022.2) and is something I use in my day-to-day. Check the Timeline tab to make sure parameter substitution is happening in a way that you expect. It's also worth mentioning that values for substitution don't get URL encoded.

[douglascamata]

For updates on this, please refer to this comment.

[Sebi2020]

Why isn't this a core feature of insomnia? For example path parameters are pretty common but we now having 2022 and they are still not implemented in insomnia.

[Vap0r1ze]

literally

[ValKiriann]

Hi, any news on this?

[Otiel]

Back to Postman because of this. 😞

Using the insomnia-plugin-path-parameters plugin is not ideal because it is not perfectly integrated (for instance, the "URL preview" displayed on the "Query" tab is incorrect).

[DrGrognon]

Hello ! +1 on this feature
Love insomnia but will keep postman at work only for this path param not being handled (and i'm sad i have to 😢 )

[kayleecodes1]

I agree with a lot of the recent comments. I recently began using Insomnia and I love everything about it but this is such an incredible oversight. Path parameters are such a standard requirement when interfacing with APIs, I was shocked to find it wasn't a feature in Insomnia.

The workaround plugins are okay but it would be ideal for it to work similar to Postman where there's a dedicated tab for path parameters. It's so janky to go into the Query tab and have a disabled attribute that gets pulled into the URL.

I'd be very willing to do the work and submit a PR. Is there any sentiment from the maintainers as to whether this feature would be supported?

[chulapitta]

Second this. I'm considering onboarding my team to Insomnia but so shocked that you cannot use path parameters in the request URL. We've been using this REST pattern as a standard for our Django backend for a decade so seeing an API design platform not supporting it is mind-boggling.

[subnetmarco]

I am catching up with this issue, and I want to discuss a way to prioritize it and move forward.

At the moment this is the situation:

• You can enter placeholders in the path of a request using the {{placeholder}} syntax, which requires to enter an environment variable in the collection.
• The dialog that asks the user to enter the placeholder value is actually quite annoying, because the value cannot be entered directly, but instead we have to go to the environment variables configuration and insert it as a JSON property.

Based on the conversation above:

• Support :param in addition to {{placeholder}} so that both can be used and people migrating from Postman have an easier experience.
• Allow to value these path parameters in the same way today we can enter a value for a "Query parameter", perhaps under a "Path parameters" section.
• When {{placeholder}} is used anywhere in the application (in the path or anywhere else), also update the dialog to allow editing the value right away:

Update this dialog so that the value can be entered right away if the environment variable is missing

Would this be an acceptable solution to move forward with?

[subnetmarco]

Hello everyone,

Path parameters have shipped in Insomnia 8.6 GA, available today. Now you can enter both environment variables or path parameters in the format of :pathParam and it will show a new section below the query parameters to value the path parameters, as discussed in this thread.

Here I have highlighted the areas of interest:

We will be going to ship a minor 8.6.1 release sometime next week to fix some UI quirkiness, feel free to send feedback. In the minor release next week, we may also ship the ability to edit an environment variable by clicking on it, which was also part of this conversation.

[kayleecodes1]

Amazing news! Thanks so much for the update.

[mitasov-ra]

Please consider updating issues related to this discussion, there's a lot of people subscribed to them (I am too), which are still waiting for updates.

[subnetmarco]

@mitasov-ra what issue are you referring to?

[subnetmarco]

Closing this has it has been implemented, still tracking internally the ability to enter a missing environment variable directly after submitting a request, but I consider this to be an enhancement.

[Vap0r1ze]

didn't think i'd live to see the day this closes as completed, thank u devs much love 💗