When running my requests individually or in a collection, they work perfectly fine. However, whenever running them with a monitor, I receive a 400 back from my endpoint. Does a monitor do something funky to the body of the requests?
I’ve already tried: Different body types and sending the necessary info in params as well as in headers. Some combinations work with getting a positive response from the endpoint when running individually or in a collection run but none of them receive a 200 from a monitor request.
This is my result after running it from the monitor. I don’t have any actual “tests” in the tests, just a way of extracting some information for subsequent requests.
I’m mostly just curious to see if there’s something I’m doing wrong or why running requests through the monitor changes the result. Thanks in advance!
Also, I should note that the “toJSON” being undefined was just me messing around and trying to figure out a way to see more information. I’m aware that it’s not going to work. I was mid-testing when I took these screenshots
I was hopeful your suggestions would’ve worked but no such luck so far. The green bars were not successes, they were just instances where the text actually just came back and showed the response body. I’ve also reset the settings on the request to default as well as the settings on the monitor.
I forgot to mention that I removed the params as you suggested as well. I also should mention there is a Content-Type header in the request (“application/json”).
Have you tried deleting the monitor and recreating it?
I know that’s the typical “have you tried turning it off and on again” approach, but it could be that there is something lodged in cache somewhere…
Im running out of ideas, because mine looks identical to yours.
I didn’t try that but I did try creating a new monitor and it had the same problems. It’s very funny what is happening with this. Could it be a paid service thing? I have a free account so I’m not sure if that has anything to do with it. Also, I tried adding in the custom Host header and now I’m at least getting a json response instead of the html!!
I checked the username / password and they are correct. I have verified as well by running the authenticate request and have received a “success” response. I used to receive the same “incorrect credentials” when trying to curl from my computer. That’s why I was looking for a service like postman in the first place
The double slashes are because I have collection variables that are populated in the test from the first authenticate request and are then used in the api calls for the subsequent requests. Since the first request is failing, those values are not populated thus the variable is empty.
I am going to try switching from raw body to form-data or x-www-form-urlencoded with this new custom host header to see if those work.
Yeah, no luck. When running the requests directly using form-data or x-www-form-urlencoded (with the other bodies emptied), I get the following from the individual request as well.
Have you tried running this in the Postman browser… Wondering if this is something that is affecting your client… Firewall or something like that? …
Okay! So everything is working in the client! Must be something with the browser version.
I’m on Chrome Version 102.0.5005.115 (Official Build) (64-bit)
Seems like maybe some of the headers are stuck to on. I can disable them in the client but in the browser, they toggle back on. Perhaps this is something? Also, it’s possible maybe some old info about the requests is cached? I’ll try clearing my cache and see if that helps.
