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.
Could you screenshot the output from the monitors? Is there anything in logs that would help to identify any issues?
This image shows when I run the request directly from the collection.
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
What does your monitor console log look like?
I just tried to replicate this and mine seems to work …
Wondering if you have changed a setting in the settings menu (there is a green dot suggesting you have) ??
You also have params (most likely unticked) but could try removing those completely so it definitely only triggers the raw body data.
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”).
This is really bugging me …
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.
On the off chance that the Host header isn’t passing the right value… you could try hardcoding the “Host” header …
You’d need to add it in like this;
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!!
Line 4 says username or password is wrong… check those.
and, line 9 shows the path as admin/game//leaderboards … should there be a double // in that path?
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.
It’s strange that using raw body with the json will work with the request but not with the monitor though
Have you tried running this in the Postman browser… Wondering if this is something that is affecting your client… Firewall or something like that? …
I’ve only been using the browser version. I’ll try downloading the client and setting up the stuff there.
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.
try logging in via incognito too