Common headers

[LaughingJohn]

Hi,

Firstly I just wanted to say thanks, I've been looking for a less bloated postman replacement and this is a really promising project. Nice clean interface and very quick.

I've only just started looking at it, and am fairly new to postman, so it's possible that I just haven't found how to do it, but one thing that would be really handy would be the ability to supply common headers to all calls in a collection.

Ideally these would be at two levels, the whole collection and the environment. If they have the same name, I imagine the headers defined in the method would take priority, followed by the environment, followed by the collection level. As an example, you could supply different auth headers for different environments without having to add the header manually to every method.

I realise I can add the header to each method and use an environment variable, but common headers would make things even easier.

Thanks again,
LJ.

P.S One other thing I miss a bit from postman is method-level variables, so I can easily change things without editing the URL directly (again it's possible I just haven't figured out how to do it)..

[Alexandre H.T.R. Bonfitto]

Hello,

You can use collection-scoped auth to have many requests sharing the same authentication scheme, like this:

1. In your collection, click on Auth in the left panel, then select a type and fill the parameters, like: Bearer with {{MyBearerToken}}
2. In your requests, click on Request > Auth and then select Inherited from collection

You might also want to take a look into the variables docs.

On having collection-scoped headers and method-level variables, although Postman has these, my humble opinion is against, because it's a not common enough user need, and adding features takes screen space, making the app feel bloated.

[LaughingJohn]

Hi @alexandrehtrb,

Thanks for the reply. In my case I'm dealing with an API that uses two non-standard headers (both some type of token) for authentication and has an additional header that may change depending on which data source we want to point to. These vary depending on the environment (Prod, QA etc). I used authentication just an example and unfortunately the collection-scoped auth doesn't work for me (unless it supported non-standard headers).

I imported the project from postman where we have the headers at the collection level and they got lost in the import.

I can of course go through and add the headers to every request and use a variable but there are a lot of requests so it's a bit painful.

I understand that you don't want to overcomplicate things though. Thanks for the consideration and good luck with the project.

[Alexandre H.T.R. Bonfitto]

Actually what your are saying is quite common, it's like a X-Api-Key header, right?

Maybe we could add this to the collection-scoped auth, as in "Add extra headers" option

[LaughingJohn]

Hi @alexandrehtrb,

Yes that's correct. I think we have a total of 4 actually, one of which is optional:

• x-auth-token
• x-token
• x-api-key (apparently this one is optional in my case)
• datasource (not auth related, but related to where the data comes from)

Although it's an API produced within my organisation it's a totally different part of the company so I have limited influence on the design. I'd imagine that there are 3rd party APIs that have similar requirements too.

The auth related ones vary depending on whether I'm calling Prod or QA which is why I liked the idea of having it at the environment level, but I guess if the collection level auth headers could use environment variables that would work too!

Thanks for taking an interest!

[Alexandre H.T.R. Bonfitto]

Solved with release 3.2.0