Insomnia: [Feature] 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.

[ryburn52]

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.

[catlinman]

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!

[cytodev]

_Bumping with a status update request_

I'm seeing multiple closed FRs and no commits or PRs mentioning this issue. How far down the line is this feature?

[z0vsky]

Also bumping as this is an interesting feature.

[gschier]

This seems to be getting a lot of traffic. I'm currently working on revamping the sync system so won't have time for a while so it might have to come from a community contribution

[jabagawee]

Isn't this solved by the Insomnia Prompt Template Tag?

[gschier]

Interesting comparison @jabagawee, I never through of it that way. I'm curious to hear other's thoughts

[catlinman]

After looking into what @jabagawee wrote about template tags I can safely say that they do everything I would have wanted in my previous message. Didn't even know they existed until today and so far they're working great! Thanks!

[ryburn52]

@jabagawee where is the documentation for Prompt Template Tag? i can't see it under Template Tags

[ryburn52]

@gschier Ok i figured out that the Promt Template Tag is a built in template variable option. After Testing i can say the following.

Technically yes it does work around the problem i had of being able to provide values per request. However i feel it introduces come UX problems.

a. You need to re-enter values each request. This can be painful if you testing an endpoint with a specific set of variables, like you want to test a specific id for this session, but next time it might be a different id.
b. It is a bit of a hidden feature
c. Having multiple prompt variables will produce multiple popups prompting one at a time. This could be done ahead of time all together.
d. I think having a section inline at the bottom of the design window that displays what variables have been resolved to and allow you to override any of them could still be useful. It wouldn't be limited to just Prompt Tag variables and would allow you to set values before the request is made. It could be set to reset when you close Insomnia making it session specific.

[ggicci]

1. /users/{% placeholder "user id" %}/posts/{% placeholder "post id" %} vs. /users/:user_id/posts/:post_id, I prefer the latter. Are you happy to type so many letters and finally make such a tedious URL?
2. Instead of bringing up new tabs or windows, why not integrate it with Query tab? The Query tab is used so frequently. #364 had already pointed out the right solution, which is user-friendly, IMO.

[brilang]

I like the second option @ggicci mentioned in his first point.
/users/:user_id/posts/:post_id
It would be very easy for people migrating from Postman to learn since that's how they do it. See attached screenshot for the Postman UI

[ryburn52]

@brilang this wouldn't help with session level variables in a Post body though would it? You could do something similar but maybe don't limit it to variables in the Path but rather any variable that impacts the current request.

[dRoskar]

There could be an url parameters table right above the query parameters table in the same Query tab.

[hungtcs]

Is there any progress in this feature?

[Azumi0]

2020 and still not a sign of this feature :( I guess I have to use postman untill this becomes a thing :(

[hungtcs]

I need this feature because I want to solve the encoding problem

[ValKiriann]

I think this feature would be awesome, please consider it. thanks for all the hard work

[chaosKP]

It seems there is already a plugin available: https://insomnia.rest/plugins/insomnia-plugin-path-parameters

[SylannBin]

Yeah, the insomnia-plugin-path-parameters is the "best" solution so far.

However, it is not completely integrated in the app. For example, the url preview in the Query tab is incorrect.

---

About the template tag, I find this feature not that practical since you are prompted for each and every prompt variable that needs to be resolved when a request is sent.
In fact it could be OK, if we were prompted on demand only (click for example) :sweat_smile:.

Otherwise, a "path params" or "request variable" tab would probably do the job.

[SylannBin]

Since my last comment I have tried creating a simple template tag to replace the Prompt tag. With just a value (and a label) in the form. That way I can set a value when I want and not be prompted all the time.

See plugin code

module.exports.templateTags = [
  {
    name: 'variable',
    displayName: 'Variable',
    description: "A variable that can be edited directly in a form",
    args: [
      { type: 'string', displayName: 'Label', help: 'A label to identify the variable.' },
      { type: 'string', displayName: 'Value', help: 'Enter a value that matches your need.' },
    ],
    run: (context, label, value) => value,
  },
]

It works... But the name is always the same :/ So you end up with urls like this:

I have tried to get the tag to show my chosen label, but liveDisplayName doesn't seem to do anything and I don't see anything else that would work... appart from a really finicky hack that would get you this kind of url:

See the gory details...

This solution isn't really acceptable in my opinion but I guess it could help until a better one is found.

Also it only works you don't have too many labels (or you love to update and reload your plugins all the time, no judgement 😄 , I know I could, but not the best for a team of several people).

And the plugin would be like:

module.exports.templateTags = [
  {
    name: 'variable',
    displayName: 'Var',
    description: "A variable that can be edited directly in a form",
    args: [
      { type: 'enum', displayName: 'Label', help: 'A label to identify the variable.', options: [
        { value: 'group_id', displayName: 'group_id' },
        { value: 'user_id', displayName: 'user_id' },
        // ...
      ] },
      { type: 'string', displayName: 'Value', help: 'Enter a value that matches your need.' },
    ],
    run: (context, label, value) => value,
  },
]

This works, but this is not really practical.

---

This lead me to think about the current environment variable form that is accessed when you click on a variable tag (base_url in my screenshot above).

Currently, it shows an enum (select) of available variables, and a preview of the selected variable.

Would it be hard to change this Preview into an editable input?

Personally, I always expected it to be editable, and I just realized with these tests that it would be a great solution, for me at least.

[guidoarce89]

I see the path params like env variables but to request level. I think I could define path params in my env variables but need to replace for some tests in specific requests..so I see as another layer of env variables but with the highest priority

[Vap0r1ze]

I wanted to use this, so I forked the app and added a params tab:

After reading the contributing guidelines, I'm not so sure if a PR would be welcome. Let me know!

[rezonant]

The contribution guidelines seem pretty normal, I see no reason you shouldn't PR it! On behalf of everyone else watching this issue and hoping for this feature, I appreciate the effort! I will say though that there is already a way to specify placeholders with ctrl+space for environment variables, maybe you could hook into that system?

[Vap0r1ze]

How cool! I'm new to Insomnia forgive me haha. I should probably add a new type of placeholder for params; I'll give that a try and keep you updated.

[develohpanda]

Hi @Vap0r1ze! Usually it's nice to discuss and agree on a particular approach so that there is less need for rework. But, seeing as you already have something running, feel free to create a PR with some notes on your design/thought process, and we can discuss specific implementation details further. I, too, appreciate the effort!

I will add that I'm not quite sure on what the best solution for this problem is yet, there are a number of valid approaches suggested here.

[gschier]

Note that there's also a simple params plugin to achieve that feature, specifically https://insomnia.rest/plugins/insomnia-plugin-path-parameters

[douglascamata]

This is the only reason why I don't use Insomnia currently. I work with a lot of restful APIs, full of parameters in the URLs. I would love to see this given the attention it deserves. <3

[scollovati]

Agree. This should be a core feature. The plugin insomnia-plugin-path-parameters is very useful, but also confusing since the url preview is wrongly built.