# (Pseudo-)chaining requests \*outside\* of a Collection Run **URL:** \ **Category:** Help Hub\ **Tags:** collections, collection-runner\ **Created:** [October 1, 2024, 2:00pm UTC](https://community.postman.com/t/pseudo-chaining-requests-outside-of-a-collection-run/69134 "2024-10-01T14:00:01Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![gwynethllewelyn](https://sea2.discourse-cdn.com/getpostman/user_avatar/community.postman.com/gwynethllewelyn/32/30275_2.png) [@gwynethllewelyn](https://community.postman.com/u/gwynethllewelyn)\ **Post date:** [October 1, 2024, 2:00pm UTC](https://community.postman.com/t/pseudo-chaining-requests-outside-of-a-collection-run/69134/1 "2024-10-01T14:00:01Z")
Hi, casual Postman user here 👋 **TL;DR** : I have an API request which, as its result, has some parameters to call a second API request. The parameters are pushed to a scope visible by both. How do I call another request _outside_ a Collection Run from the post-request code? The only solutions I’m aware of are: 1. Place the two API requests on a single folder or even in a single collection, and run them in order. 2. Forget the second request, just use `fetch()` from within the post-request code. None are really acceptable, for the reasons below 👇 > **\[Full question text takes about 8 minutes reading time\]** > > > **Disclaimer:** By “casual user” I mean that Postman is _not_ my primary tool for calling APIs, doing testing, and so forth. However, it’s incredibly useful for _simple_ API testing, without much fuss. In other words: I use Postman as a glorified version of cURL. It’s neater, it has lots of bells and whistles, it does a little more hand-holding (and error checking!), and, of course, it persists everything forever on the cloud (unlike quick-and-dirty shell scripts which get ‘lost’ easily enough…). > > After the disclaimer, here is my issue. I would love to be able to chain together just two simple isolated requests, or possibly more, picked out of a pool of possibilities. I do _not_ want to write endless duplicated collections, one for each sequence. I do not even need to do a very complex, data-driven, automated testing solution, like it’s shown on [this thread](https://community.postman.com/t/setnextrequest-doesnt-work/17506) and a few other besides that. Most involve a much more complex testing environment than what I need; I’m also using _very basic_ APIs with a reduced set of possible requests. > > Suppose that there are, say, only 6 possible requests for a particular credits-based API, named A, B, C, D, E, and F. However, _some_ have an implicit dependency — part of the returned data from the first request are parameters to pass to the next request, which will be sequentially called. At the end, let’s say, F, will almost always be called, which essentially returns how much credits are still left after the others have been called (F, by itself, doesn’t ‘consume’ credits, but abusing the system by making unnecessary requests is frowned upon). > > This API essentially contacts a remote facility to process images. The first request, let’s call it A, sends the image as raw binary data, and possibly some extra parameters to let the system know what kind of image processing is desired. The response will include some metadata on the image (or an error) and a _different_ API endpoint, from where the processed image can be downloaded — on a _separate_ request. > > So, in this scenario, A gets called with a payload for remote processing, and the response includes some data (usually a GUID of some sort) to retrieve the processed image using the request C. Calling C _without_ any valid data (well, beyond authentication) will produce an error, so it does **not** make any sense to test C on its own. C is only important in the context of having previously called A (and, of course, there _is_ a timeout — after some hours, the images will be deleted from the servers — both the raw, unprocessed image as well as the process). > > From the perspective of a simple, manual test, one presses `Send` for making a request to A (after selecting a file for upload), and it returns the image ID. This gets extracted from its JSON container and stored into a Postman variable, in an accessible scope for the collection. > > Then, the human operator can manually launch C. C relies upon that Postman variable in scope to have a valid ID. If that isn’t the case (checked on the pre-processing script), well, then it throws an error and aborts. But if the variable is set and looks plausible (it has the expected format), then C is invoked. This time, the body of the response will include the processed file, which the manual operator can then save locally at will. All of that is pretty straightforward and doesn’t require a huge amount of knowledge (or _I_ woudn’t be able to do it). > > You might ask… what about B? Why did I skip it? > > Well, B is a _separate_ entry point. Here, instead of sending the payload as part of the request, you send an URL to the image you wish to process, which has presumably be placed on a public repository of some sort. While the request for B is quite different — now it uses JSON in its body, as opposed to a raw image — it nevertheless returns exactly the same kind of response as in the case of the A → C sequence: the remote system will, again, reply with some metadata and the processed image ID. > > From the perspective of the system invoking the request, the response from B is absolutely identical to the response from A. In Postman, there seems not to be a way of somehow storing the post-processing code separately from the individual requests (more on that later), so wha I did was to duplicate A and just change the body to be sent. The rest is identical — duplicated code, which I hate, but it seems to be the only way to do it (or maybe not…). > > So, now I have two mini-workflows, with clearly defined sequences.: > > A → C > B → C > > Now, for such a basic scenario, one might argue that the collection is so simple that all I could do is to place A, B, and C (and possibly F, which will run afterwards to show how many credits have been ‘consumed’ so far) in the same Collection, and just run them in sequence. But you see where the problem is: A must invoke C immediately after it receives a response. B _might_ be called after A, or in parallel via A, or even _before_ A, so long as it calls C _independently_. My naïve approach of storing the image ID in a variable in scope will thus have dramatic consequences from potential race conditions. > > Still, I believe that, by very carefully checking for the proper sequence (and using `setNextRequest()` as intended, it might be possible to use the Collection Runner. > > Since at the end of the request, the user very likely will want to know how many credits are left, presumably request F will follow either one of them: > > A → C → F > B → C → F > > Now, let’s tackle D and E. These are ‘variants’ of… A, B, _and_ C. In other words: in some cases, after invoking C, there _might_ be _additional_ imaging data to be retrieved, e. g., there might be more than one image available — such as images in different sizes and formats, downloaded separately via different requests at different hierarchical levels. Or the file format requested for the final image might be different than the original one. Or the image original might get called in a completely different way. In fact, it’s even possible to ‘chain back’ the response (since it contains a valid URL, after all) in order to select a different tool in the chain: > > A → C → D → E → F > B → E → F > … > > and so forth. > > While the _multiple options for the next request_ might be programatically defined (as seen > on the quoted issue, above), and such ‘programming’ can conceivably replace the usual flow of a Collection Run by a custom-made one, I don’t quite see how multiple, unrelated sequences of workflows can be accomplished without either > > - creating multiple collections and/or folders, each with its own sequence, thus requiring duplicating requests over and over again in each collection/folder; _or_ > - writing your own workflow system (again, as can be seen in the linked thread above). > > Neither is an acceptable solution for me. In the first scenario, dealing with several duplicates which quickly get out of sync is a painful mess, to be avoided; in the second scenario, I would just like to point out that it defeats the purpose of using Postman at all. I could simply stick to good, old shell scripts with cURL calls (or do something fancy in Go), instead of spending time tinkering with Postman’s programming capabilities so that, well, Postman behaves un-Postman-y — which would ultimately make no sense at all. > > I’m also aware that you _can_ have collection-wide functions (and possibly folder-wide too?), which, however, will be run for _every_ request in the collection. Obviously, each request can run just a conditional branch in a function which handles the possible cases. In other words, instead of having per-request pre- and post-processing scripts, there would be just one, collection-wide, which would set up everything properly for each request. While I sort of dislike that approach (again, I’m reminded of shell scripts calling cURL…), it seems doable. > > Another possibility would be to consolidate some of the requests which are sufficiently similar into a single one. Consider the two very similar workflows, A → C → F > and B → C → F. In my use case, A and B essentially only differ in the way the image is sent for processing: in A, it’s a raw file as payload; in B, it’s an URL instead. You could have a combined request, **AB** , which would check for the presence of a raw payload and tweak parameters so that A is called; else, it would check for the presence of a JSON body with a link to an image, and behave as B; if none were preset, it would simply just abort with an error. > > This is feasible for those (few) cases when the difference in requests is mostly due to different parameters, the rest (including the actual API request) remaining essentially the same (including the rsponse!). Thus, the ambiguous A→ C → F > and B → C → F would be replaced with a single folder for AB → C → F instead. That _might_ work, with proper documentation on how AB is used in practice. It might be harder to incorporate D, E and others, which have much more complex relationships. But it’s a possibility. Another advantage with this approach is keeping the request descriptions similar in Postman to what the actual API looks like. > > And, of course, you can make `fetch()` calls on the post-request code, to avoid having C completely. In essence, therefore, I would just have an ‘ABC’ request. It certainly works, even with some extra bells and whistles (having `fetch()` properly wait until the request completes, and so forth), but… it’s hardly the ‘original API’ any more. Instead, it’s a mini-application on its own. > > One might argue that the API I’m following is not necessarily a _good_ example, breaking several good practice rules from ‘true’ REST. I would be the first to agree with that. However, most APIs I come across are relatively basic, very simple, and hardly ever follow ‘true’ REST or any similar fully documented API framework. Nevertheless, I need to test them out, and what attracts me most to Postman is the ease with which so many things are already pre-implemented ‘out of the box’, so you essentially focus only on getting the URLs right, pass the adequate parameters, and let Postman deal with the rest. > > On the other hand, using the more advanced capabilities of Postman in order to create a fully-fledged application — a test suite, if you will — is a _different_ usage of Postman, IMHO (as a casual user… remember?). Postman is a great proof-of-concept prototype builder. As a fully-fledged application framework… well, you can certainly use it that way. But it’s just not worth the time of essentially duplicating everything — on Postman _and_ my own application — just to be sure that I got it right… > > Perhaps there is something hidden deep in the documentation which I totally missed. Perhaps there is life beyond `postman.setNextRequest()`. Perhaps there is really a much simpler way of chaining requests in an ad-hoc way — such as a hidden variable somewhere which can contain the name of a (chained) request (or its ID) which gets fired just after the > > Any suggestions on how to think about Postman differently are welcome. > **Additional Platform Details** > > Postman version 11.14.1 > UI Version: 11.14.1-ui-240925-1856 > Desktop Platform Version: 11.14.0 (11.14.0) > > System version details for the client running Postman: > macOS Big Sur 11.7.9 (20G1426) ---
**Author:** ![michaelderekjones](https://sea2.discourse-cdn.com/getpostman/user_avatar/community.postman.com/michaelderekjones/32/14819_2.png) [@michaelderekjones](https://community.postman.com/u/michaelderekjones)\ **Post date:** [October 2, 2024, 11:01am UTC](https://community.postman.com/t/pseudo-chaining-requests-outside-of-a-collection-run/69134/2 "2024-10-02T11:01:12Z")
The problem that I see is that you are dynamically testing the scenarios. You should have predefined scenarios that either send request B or they don’t. It should be expecting the same results each and every time you run the collection. The same applies to the following statement. > in some cases, after invoking C, there _might_ be _additional_ imaging data to be retrieved, _There might be._ There either should be, or there shouldn’t be. You need to know the expected outcome. It should be the same result each time you run the collection. If you have a bunch of predefined scenarios in a CSV file, you can use the data file approach. No need for setNextRequest() or any real workflow. By default, this will run all of the requests in your collection for each line in the CSV. But if you have a column in the CSV which dictates which requests should run, then you can use the Postman [skipRequest()](https://learning.postman.com/docs/tests-and-scripts/write-scripts/postman-sandbox-api-reference/#skip-request-execution-from-pre-request-scripts) function to skip certain requests. You can store the requests that should be skipped as an array in the CSV file, then you can do a simple IF current request is in the array then skip this request. ---
**Author:** ![system](https://sea2.discourse-cdn.com/getpostman/user_avatar/community.postman.com/system/32/29796_2.png) [@system](https://community.postman.com/u/system)\ **Post date:** [November 1, 2024, 11:01am UTC](https://community.postman.com/t/pseudo-chaining-requests-outside-of-a-collection-run/69134/3 "2024-11-01T11:01:14Z")
Closed on November 1, 2024, 11:01am UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.