Get Request ID from UI for postman.setNextRequest

[nithyamuth]

Whenever the request display name is updated, the name needs to be changed everywhere it is referenced either by the find and replace or updating the environment variable if it set as environment variable.

This would be made easier if each request is assigned an ID and we can reference the ID in the scripts rather than the display name. So updating the display name wouldn't affect the script.

[numaanashraf]

@nithyamuth Thanks for the suggestion. "postman.setNextRequest()" does accept request ID, but unfortunately this ID is not easily accessible from the Postman UI. We'll take this as a feature suggestion to make the request IDs more accessible.

[rophy]

@numaanashraf Knowing it might be un-friendly, could you kindly comment how to obtain the request ID?

[s3bsch]

The request ID can be retrieved via the web client. When viewing a request the URL looks like …/request/111111-fdc31f9c-b34b-54fb-98n8-e7c7170ddac7.

The fdc31f9c-b34b-54fb-98n8-e7c7170ddac7 is the request ID part.

The 111111 seems to be the collection ID.

(Changed the IDs before posting them.)

[numaanashraf]

IDs are available under the info section on the new Postman Interface (Postman for Web and Postman for Desktop v8.0)

[luciantrulea]

are the request ids changing each time we import/export a collection from Postman? Is the use of the postman.setNextRequest("2ssd34223....eerere3342") hard-coding the requestId an option when working with Postman+Git+GitLab and running tests with Newman?

I have the impression that when exporting the collection that contains the above described setNextRequest(...) calls it seems that Postman isn't finding the request, could someone please advise?

[coditva]

@luciantrulea Exporting a collection can result in losing the IDs. If your workflow involves exporting and importing a collection, it is advisable to use the request name in setNextRequest. Ref: https://learning.postman.com/docs/running-collections/building-workflows/#setting-the-next-request

---

Looking at your use-case it seems you might be exporting the collection for running it in Newman. If that is the only reason for export, might I suggest that you can run a collection from Newman without exporting it:

newman run https://www.postman.com/collections/cb208e7e64056f5294e5

You can get the link for the collection by sharing it. This way you can always run the latest state of the collection in the CI without having to export it each time.

Ref: https://learning.postman.com/docs/running-collections/using-newman-cli/command-line-integration-with-newman/#getting-started

[luciantrulea]

Thank you very much for your response, in my case I have to pass via the export, as the tool I finally use to run the tests is Team City, and I have to pass trough git and GitLab in order to run the tests with the full no-regression campaigns, so I guess using the request Id is not a good option right now.

[bounteous-alisWard]

are the request ids changing each time we import/export a collection from Postman? Is the use of the postman.setNextRequest("2ssd34223....eerere3342") hard-coding the requestId an option when working with Postman+Git+GitLab and running tests with Newman?

I have the impression that when exporting the collection that contains the above described setNextRequest(...) calls it seems that Postman isn't finding the request, could someone please advise?

Every fork, every copy, every unique import. Everything in a collection receives a unique one. I found this out the hard way when trying to run monitors in a dev fork that had setNextRequest() routing configured with the immutable GUID value. It's sad, but better to use the string compare method if you use setNextRequest() and make sure to give every copy of "Log In" (or whatever) for end to end tests a unique name where you must reroute execution traffic.