When I run my workflow locally (hitting the run button) the flow receives defined header in the request
But when i deploy the the flow and pass the ‘Authorization’ header to that flow i get the error that doesn’t present in the flow
If i change my flow to handle ‘x-auth‘ instead of ‘authorization‘ header it works correctly. So there is a problem with conflicting “Authorization” header
I don’t want to use any other header, i need to utilize ‘authorization’ header. Is it a bug?
Hey @mikhaelian-r 
Is this still an issue for you with your flow?
Potentially, @lunar-module-1 or @flows-daniel might be able to help here. 
I’m curious why you need to use the authorization keyword specifically like this? When sending that keyword we expect something like bearer or basic to determine the schema.
You are correct that in the scenario we don’t enforce this vs the actual server call once it’s deployed. Will file an improvement for this.
Hey
Im working on providing integration for clients of our company and we needed to provide some tools to our clients which they will use in order to test their integration with us.
One of the step of the integration is they should send a “callback“ http request and on our side we should check if the signature which they pass in the authorization header is correct.
I found that postman flow are perfect match for that job, it can receive request and then check with crypto algorithm to check if the signature is correct and return 200 or 401.
But unfortunately when I deploy this flow the authorization header is reserved and cannot be used.
I couldn’t find a solution to use postman mock servers in order to check signature so I used the postman flows
When you make the request can you share the actual headers sent? Will try to replicate and explore a fix in flows.
Can you open the postman console and share the request headers going out and coming back. This error doesn’t look like it’s coming from flows, so trying to figure out how to replicate. If you prefer you can dm me or open a support ticket if there’s sensitive info in the headers you don’t want to post here. We’ll figure this out.
Sorry, didn’t get what you meant. Here is the log from the console
POST /api/default/callback HTTP/1.1
authorization: d290d739e22d2f050c096b991349e2df2aacf19429ff17cfbeeb321c351a4da5c9f9f402bf048e92fe921f92de23fa53bdf98ce3dd446791bb0242514bbc36fa
User-Agent: PostmanRuntime/7.51.0
Accept: */*
Postman-Token: 7f101fd3-4884-4bbc-8488-35a60d5ff572
Host: dev-reaction-sprocket.flows.pstmn.io
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 0
HTTP/1.1 401 Unauthorized
Date: Wed, 21 Jan 2026 09:00:16 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 36
Connection: keep-alive
CF-RAY: 9c159ec7cbd40b96-MRS
vary: Origin
x-content-type-options: nosniff
x-envoy-upstream-service-time: 5
cf-cache-status: DYNAMIC
Set-Cookie: __cf_bm=cRZkB9QrszNQv82QFEOo.b2SXRRTbCwrm8gp1AY4o4w-1768986016-1.0.1.1-p3T2BhOueeyYOU4XjT5nVtdNr4u.RWFlsZuUT264GqK_Iwnx1azsqNmEIAQi22nI10Dqu.AJ1akYM9ZX2CArSc1Se8nb9SyyNpSiJRfdEk4; path=/; expires=Wed, 21-Jan-26 09:30:16 GMT; domain=.pstmn.io; HttpOnly; Secure; SameSite=None
Server: cloudflare
invalid authorization header format
OK, I understand what’s happening here. The invocation service strictly enforces that the Authorization headers for flows deployed to the cloud are bearer tokens as was already pointed out. (You can turn this feature on per flow in the deploy popover.) The intention here is that this the token provided by the system to authenticate the request before running the flow. The confusion for me arose because the error is reported in a non-standard way from this service and so I initially thought something else was a miss (we will correct the error reporting).
You’re using the same header and performing your own authentication in the flow. There are three options: the first you already explored, and it involves using a different header key. The other is for us to shift the built-in authorization to a special header and leave the Authorization header for user land. The latter will require a bit of coordination so it will not be an easy change to roll out (could break existing flows). The third is to check if the flow has authorization enabled, and only extract the header when it is. This would allow the header to pass through for cases where the flow opts to perform its own auth.
Will consider this some more but hopefully this explanation is helpful to you in terms of why it isn’t working as you expect (it’s not a bug, it’s working as intended).
Can you add the word Bearer ahead of your API key (eg Bearer abc123)? if so, that would pass the check that’s currently in place and you can do the verification after you strip Bearer in the eval bloc.
Yes, added the Bearer prefix. It’s working now, but it slightly different from what I wanted to achieve
Nice
I was doing the same thing last week, but it wasn’t working. Today suddenly it works without a “Bearer” prefix 
Thank you anyway
we rolled this update to production last night to make it work for you 
thanks for the feedback.
