Get current postman user name

[modosteve]

Need to get current logged in Postman user name in order to populate a variable used in shared collection. This allows users to search logs for the requests they submitted. This is primarily used for testing purposes.

[a85]

Closing this as the use case is not completely clear.

[simonschllng]

The use case is: if you share a collection with the team and the collection creates some objects on a server, eg. POST /pet you might want to distinguish who has posted. eg. POST /pet { name: "{{userName}}'s pet" }

[vladcll]

Another use case is: a team with multiple members has access to a request, one day someone misuses the request. How do you get to know who did it? If it could get it in a variable then we can send it along with the request as a header or as a parameter. Idealy though it would be to be forcefully send by the app itself based on some configuration accessible to collection / request owner.

Can you please reopen this? I think there's plenty of value in having this feature implemented.

[pdev23]

The use case is completely valid and specially you share the collection or test case with your colleagues

[andrewschouten]

Ah I saw this from 2018 and was hoping it was implemented. We have the same basic use case. A shared collection and would like to retrieve the logged in user and pass this as a header to help us track down who may have made the request.

[tomereli]

Its a really valid usecase indeed - any reason why it is closed?

[BenjaminMcGill]

Please reopen this... We have a team with multiple users and this would help our testing efforts greatly.

[Rclemens]

This is a valid case. Please Reopen this request

[zackheil]

@a85 I believe the followup comments have made the use case clear and it would be a great addition. Especially since shared Postman Collections in an enterprise team allow anyone to send requests. I want to know exactly who fired (or misfired) a request that made a database change. If you don't think this is a good change, then please provide advice of what you think a better practice would be. Because I've tried:

• having an email collection variable. This doesn't work on a per-user basis in a shared collection
• having an email env variable would mean having a duplicate env for every user, all of which are public to workspace members
• forcing a user to manually fill out a header that identifies them as the caller as a part of the API spec, which would be painful

[kavdiev]

in my case i would like to override the value of header "User-Agent" to have PostmanRuntime/{{loged_user}} fo in my logs i can easily make a distinction between my calls and from others tester. thanks

[deepakaggarwal7]

in my case I want useremail to be passed as header so that an email could be sent to the actual user who triggered it. having a variable like {{userEmail}} will make it error-prone as users don't need to remember updating request email to their email id everytime a different user runs request

[lucaslov]

My usecase is similar, I have some collections in which I'd like to include name or email of the currently logged in user so that we don't have to manually write it down every time someone wants to update/create some data as we have a requirement to have an information about who creator/modifier. I'd love this feature to be there for us. @a85

[nbazelev]

Same for me: I need to specify customer data such as name and email in the request body. Something like pm.user.name and pm.user.email will be really helpful.

[kd-at-mi]

In my scenario, developers all have local environments setup to work and our app requires api tokens and other information such as a few ids associated with that api token account in each environment and everyone is different because of how the ids are created.

I am looking to do something like this:

My Env: projectID='xnd3.....' apiToken='9876'

Teammate Env: projectID='d43c3.....' apiToken='1234'

We have our endpoints setup as a team workspace, so we just need to get the variable associated with that user: user1_projectID='xnd3.....' user2_projectID='d43c3.....'

set projectID = {{whichever user is logged in}}

so when we are hitting the end point we can still use

/project/{{projectID}}/list

I was planning on writing a pre-request script to assign that variable, but I would need to get some identification about which user is running the task

[DannyDainton]

Reopening this based on comments/use cases after the feature request was raised. I don't have any updates for this, I'm just opening it so the team is aware.

[antgustech]

I have the need for this as well.

[lukeduda]

That would be super helpful while working in a team, shared requests could be trackable.

[abdulrehman-sk]

We need to be able to send loggedin user's email. This becomes handy when we want to make a request to a third party account which uses the same email/metadata of the loggedin user. This would be very much beneficial.

[rich-grundy-cko]

@DannyDainton - Any idea when this might be prioritised on your roadmap?

This is a feature that we would find very useful

[essieanawalt]

+1 for this. Any sort of "this user" variable would be helpful, even if just to be able to create a pre-request script from the user id for something more defined as an output.

[TheXienator]

+1 for this as well

[kr99]

As a : 🔹 technical lead I need : 🔹accountability for who/what is creating test data in stage and possibly production So that: 🔹I can kindly talk to any engineer (self/team/dept) who leaves test data in stage/prod in a way that's messy and interferes with operation/testing/confidence So that: 🔹I can reduce the risk of test false positives/negatives, and wasted time; So that: 🔹I can plainly see why an integration test is failing - messy data from itself, an engineer, or others - and mitigate the problem for future builds.

[dkanaev]

+1

[caseyfw]

Kinda shocked this isn't a feature already.