Sheduled Runs back 403, but Single Run works well

[kartmun (Kirill L.)]

When I select 3 queries and run them in manual mode, there is no problem.
When I turn the same collection into Scheduled Run, I see that all posts have a 401 status code

I could not figure out the reason myself, help, ask questions

[kevinc-postman (Kevin)]

Hi @kartmun !

First, I want to welcome you to the community and also thank you for providing a video as this is super helpful for troubleshooting

Just to clarify, you’re only getting a 401 status code and no 403s?
A 401 status code indicates that authentication is required and the request has failed due to missing or invalid authentication credentials. If a single run in Postman works fine but a scheduled run returns a 401 error, there might be a few possible causes:

1. Environment Variables:

• Ensure that the environment you’re using during manual runs is the same one selected for the scheduled run. Environment variables might differ or be absent, leading to authentication issues.
• Check that any tokens or other authentication-related variables are properly set and being sent in your scheduled requests. One of the most common issues arises from default vs current values for variables. Scheduled runs will use your default value.

2. Auth Token Expiry:

• If you’re using token-based authentication (like Bearer tokens for OAuth2), the token might expire. A manual run might use a valid token, but by the time the scheduled run occurs, the token has expired. Consider implementing a pre-request script in Postman to fetch a new token if it’s expired or about to expire.

3. Check Console Logs:

• Open the Postman Console (from the bottom-left of the app) and run your collection manually to see all the details of your requests and responses. Compare this to what’s happening in the scheduled run.
• After the scheduled run, check the detailed logs provided by Postman Monitoring to see if there’s a specific issue or discrepancy between the manual and scheduled runs.

Hope this helps!

[kartmun (Kirill L.)]

I understand the reason, I do not attach data for variables, but after applying it, I understand that all my dynamic variables turn into a poke and become static, how can I make it run as I do it manually?

Or is it fundamentally impossible?
If so, how then to prepare test data sets? To create in advance all id which will be “test”?

[kartmun (Kirill L.)]

I try use Variables into csv, but it doesn’t work ( how I can do it?

[kartmun (Kirill L.)]

After researching the problem (Forums, Indian videos, official documentation).
I decided to analyze a detailed case, and I expect an answer on it (please).
So we have 4 requests:

1. Getting xrsf token (GET)
2. Getting Bearer token (autn POST) Headers {X-XSRF-TOKEN}: {{x_xrsf_token}} \\ Body {login \ pass }
3. Create a notification for each user
4. Remove notification by id

In 2, 3, 4 we always pass X-XSRF-TOKEN in the header (I always use the variable in manual triggers)
In 3, 4 We use Bearer Authorization (I have it from the parent, also in the variable {{token}}

Now, to the point, I prepared a test bench With outputs from the console at different stages, ran it manually, through Sheduler and Postman CLI.

And I conclude that he does not use the variable {{x_xrsf_token}} in subsequent requests exactly at the level of the Variable, in the variable itself the value is correct, but there is no connection between {{x_xrsf_token}}

[kevinc-postman (Kevin)]

Thanks for the detailed explanation @kartmun. It helps a lot in understanding your issue. Let’s try to address this step by step.

1. Dynamic Variables: When running collections manually in Postman, variables set in one request are available for the next. However, with scheduled or CLI runs, the sequence and persistence might behave differently.
2. CSV Data: If you’re utilizing CSV for variables, remember each row is considered as an iteration in Postman. The entire collection will run for each row. If you’re trying to use dynamic data between requests, relying solely on CSV might not be ideal.
3. Solution Suggestions:

• After your first request, use a test script to set x_xrsf_token from the response.
• In the second request, ensure your header uses {{x_xrsf_token}}. Also, capture the Bearer token in the test script section.
• For the third and fourth requests, reference the set environment variables in your headers and authorization sections.

4. Postman CLI (Newman): When using Newman, ensure you’re also providing the correct environment file, e.g., newman run collection.json -e environment.json.
5. Variable Verification: If you ever see {{x_xrsf_token}} as a literal string in the output, it indicates that the variable wasn’t available or set at that moment.
6. Timing Considerations: Ensure your requests run in the correct order. If needed, consider adding a delay between requests to avoid race conditions.

It’s crucial to maintain a consistent variable state between manual and automated runs. If you still face challenges, I’d recommend breaking down your collection to simplify and isolate the issue.

[Modelus]

hello @kevinc-postman

and how exactly does authorization work, when using scheduled runs? I have a fresh token for my collection I send requests to the same endpoint and URL’s are identical, in my environment all variables have equal initial and current values but I still got 401 error in scheduled run and 200 in manual.

I use authorizationCode flow of oauth2. If I do not have any pre-requested scripts ther would be no authorization at all?