Add ability to trigger another request in collection from pre-request script

[prathiraj]

[Feature request]

Add ability to trigger another request in collection from pre-request script

[tmcdonnell87]

+1 - this alone would probably get my team to upgrade to using pre-request scripts. Very common for us with one of our token generation schemes. OK if only in the packaged app and not Chrome.

[abhijitkane]

@prathiraj @tmcdonnell87 - trying to understand the use-case here -

In the pre-request script for request r1, you check if a condition is true. If true, you fire request r2, set environment variables from the response of r2, and use those variables in r1.

Is that correct?

[tmcdonnell87]

Two cases:

1 - Exactly what you said, though to elaborate, it may be a data-based condition. Only some values would require the pre-request.
2 - Usability for auth with limited-use tokens. Right now you can set the response to a previous call as the auth token, but it requires actually sending the request. If you have single-use tokens, you need to back up and get a token each time. (Also each token is good for only one API, which clutters collections.) Getting the token in the pre-request script would save a ton of time, especially for the QA team.

Thanks!

[prathiraj]

+1 to what @tmcdonnell87 said.

[nonnenmacher]

+1 also
and as a duped feature request of having more external lib available, a way to inject crypto.js like lib, will be immensely valuable.

For now it oblige to make specific collections, just to feed environments variables by calling special API calls, to compute this kind of 'auth / security / crypto' needs for token, nonce....

[ghost]

+1 this would be immensely useful.

[MarcosRava]

+1

[LeoLeal]

+1

[gadelkareem]

+1

[luisgmoreno]

+1

[42thcoder]

+1

It will change the way we test our API

[ponvino]

+1

[dominiksipowicz]

+1

[reallistic]

+1

[sp72]

+1, thanks.

[dineshk-qa]

+1, definitely need this feature

[MarcosRava]

You can use test script to populate enviroments after request

[tmcdonnell87]

Yes... but that's a very clunky process , especially if you have multiple requests in the chain or conditional logic.

[nonnenmacher]

I agree, especially if you look at the original request, that outline that
chaining scripts,
could be to populate environment data for your current/real test.

This feature is the logical next step, for progressively build a complete
set of environment variables
that could be expanded during the real value of a script/test.

Take for example a complex, crypto setup where during a login phase, some
dynamic/shared secret
are built-up, to obtain at each end such common understanding/secrecy and
feed back a token
on each requests of a postman test suite.

On Wed, Sep 23, 2015 at 4:33 PM, Terry notifications@github.com wrote:

Yes... but that's a very clunky process , especially if you have multiple
requests in the chain or conditional logic.

—
Reply to this email directly or view it on GitHub
#697 (comment)
.

[Evanlec]

+1

[loretorafa]

+2

[srbangre]

+1

[kyle-felizz]

+1

[mobiletoly]

+1

[bencami22]

+1

[stramel]

@joaovpmamede @sh3raawii and anyone else like myself who wanted this issue to allow sending of collection requests, please go over to this issue and give it a 👍

GO HERE: #4193

[ghost]

+1

[jayarjo]

+1

[AnkitKabra20]

+1

[lartie]

+1

[zankhanarana9]

+1

[stramel]

@shamasis @abhijitkane @czardoz Do you mind locking this thread so it doesn't continue to get +1s?

[magusd]

+1

[jakeNiemiec]

Do you mind locking this thread so it doesn't continue to get +1s?

➕💯

[raylapse]

• 1

[raylapse]

+2

[ghost]

+1

[Flangvik]

+2

[vosamoilenko]

+1

[attilahogyai]

+1

[parul3389]

It is may be a very late reply, but I just found something very simple, which might be helpful.
In tests area of authorization request, we can assign this request to some varibale.
pm.globals.set('authorization_request', pm.request);

And then same variable can be used into other request pre-requsite script.
pm.sendRequest(pm.globals.get('authorization_request'), function (err, response) {
pm.globals.set('token', response.json().access_token);
});

[RichFoo]

It is may be a very late reply, but I just found something very simple, which might be helpful.
In tests area of authorization request, we can assign this request to some varibale.
pm.globals.set('authorization_request', pm.request);

And then same variable can be used into other request pre-requsite script.
pm.sendRequest(pm.globals.get('authorization_request'), function (err, response) {
pm.globals.set('token', response.json().access_token);
});

This works, but the captured request is captured with all of it's variables resolved (unsurprisingly). So, if you switch environments, you'll need to re-run the authorization request to re-generate the captured request with the correct parameters. It's definitely a start, though!

[spencerrichardhenry]

Why is this issue marked as close? I see no resolution

[Dmitresky]

any updates?

[fergardi]

What I ended up using was the PreRequest scripts in a the collection itself, so that every single request inside that collection executes that script and gets the API token refresh, for example.

[bencami22]

The problem with that is you will have duplicate code in each pre request script you need an Api token.

…

On Mon, 17 Feb 2020 at 17:36, Fergardi ***@***.***> wrote: What I ended up using was the PreRequest scripts in a the collection itself, so that every single request inside that collection executes that script and gets the API token refresh, for example. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#697?email_source=notifications&email_token=AGHYD72MYQI5JI74XG4KJJ3RDK4INA5CNFSM4ATI55E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7A6YA#issuecomment-587075424>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGHYD74LUESDXLA554TSN23RDK4INANCNFSM4ATI55EQ> .

[albertlieyingadrian]

+1

[mvdcorput]

+1

[FullofQuarks]

Still don't see a resolution in this thread that was opened 6 years ago...instead I see multiple issues revolving around the same feature request, and comments like "Do you mind locking this thread so it doesn't continue to get +1s". So instead of addressing the issue (I continue to see activity on this issue, #4193 and #4845), you'd rather lock it so no further comments can come out of it.

Either close all the issues as "wont-fix" or actually consolidate them all into one issue (as requested last year in #882). Or maybe we can discuss the issue. You know, like what GitHub issues are for.

[jdelpierre]

+1

[MukeshMM]

+1000000

[arlemi]

Hey 👋 I've gathered all feedback from here and other issues into a single one, please add a 👍 reaction to the first post there if you'd also want that feature.

➡️ #4193 (comment)