The objective is to avoid passing it every time and rather the request inherit the parent folder's settings.
It would also be useful to override the parent folder's headers if the request had the same header.
Thanks
Hi @nsankaranarayanan. There's no way to do this at the moment, but it's a highly-requested feature.
I've been trying to think of a clean way to do this for a while, and just had an idea.
The headers tab could include include a <select> dropdown at the bottom and let the user choose an environment variable to include headers from. The environment variable could be a simple key-value object and could be included in either the global/sub/folder environment.
Here's what an example environment might look like:
{
"headers": {
"Accept": "application/json",
"Authorization": "token 1234"
}
}
I think I'll play around with this today and see if I can get something working.
I am open to the idea though I want to emphasize one thing. You currently have a good way of implementing substitution parameters. While implementing this don't lose that.
The existing functionality would be preserved, but there would be an additional option to extend an environment variable. I'm thinking something like this:

Waiting for release.
Closing this one in favor of #447
If anyone is still wanting this, I created a simple plugin to do it. It uses a special environment variable to pull header configuration from: https://www.npmjs.com/package/insomnia-plugin-default-headers
Yes, Initially, I want such a method to pass authorization header, however I always copy from existing request as walkaround.
And maybe this can be a first-class function but not a plugin.
Previously, I always copy from existing request, but often with something I don't want.
@gschier and you've mismatched insomnia in the plugin name.
@wonderbeyond for authentication, you probably want to follow #447
Also thanks. I fixed the typo.
@gschier Thanks! #447 is awesome idea!
I've been always copying existing requests, waiting you save me.
Most helpful comment
The existing functionality would be preserved, but there would be an additional option to extend an environment variable. I'm thinking something like this: