Disable Temporary Headers

Hey @Dachmo,

I would love to understand where it’s failing for you and what led you to the point of knowing that it was the headers and the behaviour of the temp headers with Postman that caused it.

I’m just trying to gather more information around this to expand more own knowledge, as the thread is full of different users from different contexts. There have only been a handful of folks who have given actual details of what they are seeing.

Would you be able to expand on your use case and share some images or details of what headers were causing you issues etc.

Also, you don’t need to sign up for Postman to use the application, not really sure where you read that. :slight_smile:

1 Like

it happened to me today morning and it took me an hour to figure out, to solve it i had to do following solution : cookies link below Send button -> go there and delete all old cookies. I am not sure how the cookies were set up there though in first place.

Thanks for responding.

My bad. I see the skip registration button at the bottom now. It has been some time since I used it last and must admit I don’t remember seeing that before. I’ll retract that part, and apologise after my frustration fuelled rant.

It is as others have said - certain services, APIs etc are expecting certain values in their headers, and ONLY those values.

I’m not able to give specifics about the rest of the headers, but for me, the “Postman-Token” appears to be the issue. I can verify this by adding and removing it in Insomnia.

1 Like

Thanks for the clarification.

That Postman-Token header and also the Cache-Control header, can be disabled in the General Settings menu. So those would be removed from the requests.

That’s not to say it’s going to solve all the issues mentioned in the thread though. It’s tough to know for sure because like I said, there hasn’t been a lot of information about the specific problems mentioned.

That’s why I’m hoping that other people will share a bit more about the context of their own issues.


I just wasted an otherwise perfectly good morning on this piece of garbage. I have an “Authorization” header in my request with ‘Bearer {{token}}’ but for some reason the temporary header has an old token that doesn’t work and now I cannot remove it. I thought it was something else until I noticed that the production environment worked, just not the test tool. Switching to a different tool until this is fixed.

+1 on the issue, it is simply impossible to use postman with elasticsearch now :confused:

I’ve also run into a situation where I’m almost certain that the temporary headers are causing an issue. I’m testing a REST API built on top of Django with the django-rest-registration module. When attempting to verify an email address through Postman, it fails 100% of the time. However, if I run the exact same command with cURL, omitting all the temporary headers, the request works fine. Disabling the no-cache and Postman Token headers do not change this behavior. I’ve not figured out which headers are causing the problem, specifically, but I’ll update if I do.

Edit - After some testing this morning, I believe the specific header that’s triggering my problem is the Accept-Encoding header. Removing that from the set of temporary headers allows cURL to successfully validate a user. Not sure if the same applies to ElasticSearch or other APIs. So I’d love a way to be able to at least turn that one off, though turning them all off would still be preferable.

impossible to develop an api with postman. flask doesn’t appreciate the temporary headers. removed postman.

I use Postman to achieve clarity so I know what I’m sending to an API. Having headers imposed is not doing anyone any favours. Please tell us when these can be switched off. The delay on this is counterproductive to your user community.

This does not work for django.

I get a response: “detail”: “Authentication credentials were not provided.” even though headers are included. In the temporary headers, my Token XXX gets overriden to Bearer XXXX and I can’t figure out how to disable this override.

It should be simple to just add a checkbox next to each temporary header. Not allowing developers full control over what we are sending to our API is absurd.

Also, the fact that temp headers are not saved with the request makes it such that it’s not true documentation.

Was considering upgrading to Pro because the product is great otherwise, but this is a non-starter.

I also have spent too much time on this problem, and I think it comes since Postman introduced the Authorization section, (https://learning.getpostman.com/docs/postman/sending_api_requests/authorization/). A feature that seem quite recent.

I have been using postman for a long time and only recently I had the following issue:

What I do:

  • sending a request with a valid header “X-Auth-Token” to authorize my user.

What I have:

  • invalid token error

What I should have:

  • a valid request and a 200 response.

I noticed that my collection Authorization was set to “Api key” with no value, and all my endpoints were set to “inherit auth from parent”

1st solution:
What I had to do since the Authorization section was introduced. Go to the collection > edit > Authorization, and setup the api key header here. and it’s all working again.

2nd solution:
Go to your endpoint settings > Authorization > change type to “no auth” (you can do that at the Collection level too)

yeah exactly the same problem. I’m trying to force my new tokens and the app keeps using old ones and does not let me override it… such really annoying thing

thanks this helped a bit still something is really weird and my request is still putting a temporary header in my request event though I want to manage that in my environment

so I want to manage 2 of my cookies. but once they are used they never manage to be updated and my override is always ignored and the temporary overrides them

my settings and collection are ignoring the authentication, did I miss understood some of the options?

just to explain what I want to do:
I need to get a first token from a request, use that token on another request and get the updated token from the second request in the subsequent requests… this seems to be a problem because once the value is set it never gets updated

Unfortunately, Postman has become unusable, I do HTTP request testing to figure the response of the server on various headers and hence need to control all the headers.

Reading through this thread I see the frustration of the community and Postman team quite proud of the mess. I wonder if this “feature” was covert sabotage by Postman’s rival.

Good Bye Postman… Insomnia is here :smiley:

1 Like

I am sad to see Postman go for me and my whole team. This feature has cost days of lost time, escalation to upper management, and simply makes no sense.

R.I.P Postman

I’m having the same issue, and the authorization header is sent with expired token and I’m not able to continue my work, because of expired token

Exactly have sam issue, wasted 2 days, Authorization header keep on sending some old token



I am not sure if anyone has tried this but if you will pass temporary headers name in your header section and leave the value as empty then postman will not pass any temporary header for that.

I hope this helps.


Are you saying to set each item blank? e.g. “User-Agent” empty

This will still send an empty key of “User-Agent:” (instead of “User-Agent: PostmanRuntime/7.17.1”)

I would rather not have to explicitly set a blank value to “nullify” the temporary headers. I don’t see the issue as being “resolved”.

The proper resolution is to make the “temporary headers” a checkbox option, and preferably defaulting to unchecked.

1 Like

Like many others in this thread, I spent a decent amount of time trying to figure out why a Postman request was failing, and it turns out it’s because the client is sending superfluous http headers.

I then spent a decent amount of time finding and reading this entire threaded discussion. I’m now super frustrated, but I want to be empathetic and respectful in hopes of appealing to someone’s sense of reason.

@richjenks said it best, it really is “an absolutely bonkers design decision” to add headers automatically (other than that which is necessary) with no mechanism to disable that behavior.

@abhijit The only data required for a valid HTTP request is the method, the Host header, the Path, and the protocol version. Content-Length if there’s a body. Everything else is optional. If you think otherwise then you don’t know the HTTP protocol.

What happens when an HTTP server is specifically designed to reject requests with a user-agent header. Is Postman’s official position that its client can’t and won’t transact with that kind of server. This whole thing really is ridiculous and that the injection of headers can’t be disabled is insulting.

With respect, there’s no justification for this. Do better!

1 Like