30 Claude Prompts for Postman

You are a QA automation engineer who writes Postman test scripts for API regression suites. <context> I have a sample JSON response from an endpoint and I need solid pm.test assertions before this request goes into our automated test suite. </context> <inputs> - Endpoint: [METHOD AND PATH, e.g. GET /orders/123] - Sample response body: [PASTE JSON RESPONSE] - Expected status code: [STATUS CODE, e.g. 200] - Fields that must always be present: [LIST REQUIRED FIELDS] - Fields with known value ranges or types: [LIST FIELDS AND CONSTRAINTS] </inputs> <task> Write a Postman Tests tab script using pm.test blocks that check the status code, response time under a reasonable threshold, presence and type of the required fields, and any value range constraints given. </task> <constraints> Use pm.response.to.have.status and pm.expect syntax, not deprecated tests[] object syntax. Keep each pm.test block focused on one assertion so failures are easy to trace. Do not assert on fields not mentioned in the input, avoid guessing business rules. </constraints> <format> Return the full JavaScript block ready to paste into the Tests tab, with a one line comment above each pm.test explaining what it checks. </format>

You are a backend engineer who has implemented HMAC or JWT based request signing for internal APIs. <context> Our API requires a signed authorization header computed from the request body and a timestamp, and every developer keeps generating it wrong by hand. </context> <inputs> - Signing method: [HMAC-SHA256 / JWT / CUSTOM ALGORITHM] - Inputs to the signature: [E.G. SECRET KEY, TIMESTAMP, REQUEST BODY] - Header name expected by the API: [HEADER NAME] - Secret storage location: [POSTMAN VARIABLE NAME, e.g. {{apiSecret}}] </inputs> <task> Write a Postman pre-request script that computes the signature using the given algorithm and inputs, then sets it on the specified header using pm.request.headers.add, using Postman's built in CryptoJS library where possible. </task> <constraints> Pull the secret from the Postman variable given, never hardcode it in the script. Include comments explaining each step of the signing process since teammates unfamiliar with the algorithm will need to maintain this. Handle the case where the variable is missing by throwing a clear error instead of silently sending an unsigned request. </constraints> <format> Return the pre-request script as a JavaScript code block ready to paste into the Pre-request Script tab. </format>

You are an API test engineer who builds multi step Postman flows that depend on values from earlier requests. <context> I have a login request that returns a token, and three downstream requests that need that token, and right now someone copies and pastes it manually every time it expires. </context> <inputs> - Login response shape: [PASTE SAMPLE LOGIN RESPONSE JSON] - Token field path in response: [FIELD PATH, e.g. data.accessToken] - Environment variable name to store it in: [VARIABLE NAME] - Downstream requests that consume it: [LIST REQUEST NAMES] </inputs> <task> Write a Tests tab script for the login request that parses the response, extracts the token at the given field path, and stores it in the specified environment variable using pm.environment.set, plus the corresponding header setup snippet for the downstream requests to reference it. </task> <constraints> Include a check that the token was actually present before setting the variable, and log a clear pm.test failure if it was missing rather than silently setting undefined. Use environment variables, not collection variables, unless the input specifies otherwise. Keep the snippet short enough to read in one screen. </constraints> <format> Return two code blocks: the Tests tab script for the login request, and the one line Authorization header value to use in the downstream requests. </format>

You are a senior QA engineer who reviews other people's Postman test scripts to find why assertions are failing unexpectedly. <context> A test script that used to pass is now failing in our CI run and I cannot tell if the API changed or the script has a bug. </context> <inputs> - Current test script: [PASTE TESTS TAB SCRIPT] - Actual response received: [PASTE ACTUAL RESPONSE JSON] - Error or failure message shown: [PASTE ERROR MESSAGE] - What changed recently, if known: [DESCRIBE RECENT CHANGES OR WRITE UNKNOWN] </inputs> <task> Analyze the script against the actual response and error message, identify the specific line or assertion causing the failure, and explain whether the root cause is a script bug or a genuine API behavior change. </task> <constraints> Point to the exact line number or assertion text that is failing, do not give a vague general explanation. If the fix requires a script change, provide the corrected script. If it looks like a genuine API change, say so plainly instead of patching around it. </constraints> <format> Return a short diagnosis paragraph, then the corrected script in a code block if a script fix is needed, or a one line recommendation if the issue is on the API side. </format>

You are a QA automation engineer who enforces response contracts using JSON schema validation inside Postman. <context> We have a JSON schema document for an endpoint's response and I want Postman tests that fail the build the moment the response drifts from that contract. </context> <inputs> - Endpoint: [METHOD AND PATH] - JSON schema: [PASTE JSON SCHEMA] - Postman tv4 or ajv availability: [TV4 BUILT IN / AJV VIA PACKAGE] - Failure tolerance: [STRICT, FAIL ON ANY EXTRA FIELD / LOOSE, IGNORE EXTRA FIELDS] </inputs> <task> Write a Postman Tests tab script that validates the response body against the given JSON schema using the available validation library, and reports a clear pm.test failure message listing which fields violated the schema. </task> <constraints> Use pm.response.to.have.jsonSchema if tv4 is available, otherwise write the ajv based alternative. Respect the strict versus loose tolerance setting for additional properties. Keep the schema embedded in the script as a JavaScript object rather than requiring an external file. </constraints> <format> Return the complete Tests tab script as one JavaScript code block, with a comment noting which validation library it assumes. </format>

You are a frontend integration engineer who sets up Postman mock servers so UI teams can build against an API before the backend ships. <context> Our backend team gave me an API contract but the actual endpoints are not live yet, and the frontend team needs something to point at this week. </context> <inputs> - API contract or endpoint list: [PASTE CONTRACT OR ENDPOINT LIST] - Example success response for each endpoint: [PASTE EXAMPLE RESPONSES IF AVAILABLE] - Error cases to simulate: [LIST ERROR CASES, e.g. 404, 422 VALIDATION] - Realistic sample data domain: [E.G. ECOMMERCE ORDERS, HEALTHCARE APPOINTMENTS] </inputs> <task> Produce a set of Postman saved example responses for each endpoint, covering the success case and the listed error cases, using realistic sample data from the given domain rather than placeholder lorem ipsum text. </task> <constraints> Match field names and types exactly to the contract given, do not invent extra fields. Include appropriate status codes and headers for each example, including Content-Type. Keep sample data internally consistent, for example the same order ID should appear across related examples. </constraints> <format> Return one JSON block per endpoint labeled with the endpoint name and status code, ready to paste as a Postman saved example. </format>

You are a reliability engineer who tests how frontend and downstream services behave when an API misbehaves. <context> Our app has never been tested against a slow or broken version of this API and I want a mock setup that simulates realistic failure modes before we ship. </context> <inputs> - Endpoint being simulated: [METHOD AND PATH] - Normal success response: [PASTE SUCCESS RESPONSE] - Failure modes to cover: [LIST, e.g. TIMEOUT, 500, RATE LIMIT 429, MALFORMED JSON] - Client behavior we are testing for: [E.G. RETRY LOGIC, ERROR BANNER DISPLAY] </inputs> <task> Produce a set of Postman mock server examples that simulate each listed failure mode, including appropriate status codes, headers such as Retry-After for rate limiting, and response bodies that match how the real API would format an error. </task> <constraints> Keep each failure mode as a separate named example so testers can select them individually. For timeout simulation, note that Postman mocks cannot truly delay a response and suggest the workaround using a delay header or an external tool. Make error message text realistic, not just the word error. </constraints> <format> Return one JSON example block per failure mode with a label, followed by a short note on any failure mode that needs a workaround outside Postman's native mock delay limits. </format>

You are a Postman mock server specialist who builds mocks that respond differently based on the incoming request instead of returning one static response. <context> Our current mock always returns the same response no matter what ID is requested, and the frontend team needs it to behave differently for different test IDs. </context> <inputs> - Endpoint: [METHOD AND PATH WITH PARAMETER] - Parameter values and expected responses: [LIST PAIRS OF PARAMETER VALUE AND EXPECTED RESPONSE] - Default response when parameter does not match: [DESCRIBE DEFAULT] - Matching mechanism preference: [POSTMAN EXAMPLE MATCHING / MOCK SERVER SCRIPT] </inputs> <task> Design the set of saved examples with matching request parameter values so Postman's mock server returns the correct response for each listed parameter value, plus the default example for unmatched values. </task> <constraints> Explain how Postman's example matching works for path and query parameters so the setup actually triggers correctly, since mismatched example matching is a common source of confusion. Keep response bodies consistent with the parameter value used, for example the returned id field should match the requested id. Note any parameter combination that Postman's native matching cannot handle. </constraints> <format> Return a short explanation of the matching approach, then one JSON example block per parameter value tested. </format>

You are an API product owner who manages a mock server that multiple teams depend on during active development. <context> Our mock server keeps changing shape as the real API evolves and downstream teams are getting broken by silent changes with no warning. </context> <inputs> - Mock server name: [MOCK SERVER NAME] - Recent changes made: [LIST CHANGES, e.g. renamed field, added new endpoint] - Teams consuming the mock: [LIST TEAMS] - Release cadence: [E.G. WEEKLY, AD HOC] </inputs> <task> Draft a changelog entry documenting the recent changes in plain language a non backend engineer can understand, plus a lightweight versioning and communication plan so future changes do not silently break consumers. </task> <constraints> Write the changelog in past tense describing what changed and what action consumers need to take, not just a list of technical diffs. Keep the versioning plan practical for a small team, do not propose heavy process like formal RFCs unless the team size justifies it. Call out any change that is breaking versus additive. </constraints> <format> Return the changelog entry as a short dated bullet list, followed by a 3 to 5 step versioning and communication plan. </format>

You are a QA lead who ensures a mock server stays in sync with the real backend it stands in for. <context> Our team relies on a mock server during development but nobody verifies it actually matches production behavior once the real API ships, and drift has caused bugs before. </context> <inputs> - Mock server endpoints: [LIST ENDPOINTS COVERED BY THE MOCK] - Real API base URL once available: [BASE URL OR NOT YET AVAILABLE] - Known differences already spotted: [LIST ANY KNOWN DRIFT] - Team responsible for keeping mock in sync: [TEAM OR PERSON NAME] </inputs> <task> Create a contract testing checklist that compares each mocked endpoint against the real API once it exists, checking status codes, field names, field types, and required versus optional fields, to catch drift before it causes downstream bugs. </task> <constraints> Structure the checklist so it can be run manually or turned into an automated Postman test collection later. Prioritize the known differences already spotted at the top of the checklist. Keep each checklist item specific enough that two different people would check the same thing the same way. </constraints> <format> Return a numbered checklist grouped by endpoint, with a short note at the end suggesting which items are good candidates for automation first. </format>

You are a technical writer who specializes in API reference documentation generated from Postman collections. <context> I have a working Postman collection but the documentation tab is empty and external partners need to understand how to use these endpoints without asking us questions in Slack. </context> <inputs> - Collection endpoints and sample requests: [PASTE ENDPOINT LIST WITH SAMPLE REQUESTS] - Audience: [INTERNAL DEVELOPERS / EXTERNAL PARTNERS] - Auth setup to explain: [DESCRIBE AUTH TYPE] - Anything commonly misunderstood: [LIST COMMON CONFUSION POINTS, IF KNOWN] </inputs> <task> Write Postman documentation text for each endpoint, including a one sentence purpose, the required parameters and headers, a sample request, a sample response, and common error responses, formatted in Postman flavored markdown. </task> <constraints> Write for the specified audience, external partner docs should avoid internal jargon and internal docs can assume shared context. Address the common confusion points explicitly rather than only describing the happy path. Keep each endpoint's documentation self contained so a reader does not need to read others first. </constraints> <format> Return one markdown section per endpoint with a level 2 heading matching the endpoint name. </format>

You are a developer relations engineer who writes onboarding documentation for external developers using a public API. <context> We are publishing our Postman collection publicly and new developers need to go from zero to their first successful API call without contacting support. </context> <inputs> - API name and purpose: [API NAME AND ONE LINE PURPOSE] - Steps to get an API key: [DESCRIBE SIGNUP AND KEY GENERATION PROCESS] - First recommended endpoint to try: [ENDPOINT NAME] - Rate limits or restrictions: [DESCRIBE LIMITS] </inputs> <task> Write a getting started guide that walks a new developer through forking the Postman collection, setting their API key as a collection variable, and making their first successful call to the recommended endpoint, ending with what a successful response looks like. </task> <constraints> Write in second person, addressing the developer directly. Include the exact collection variable name they need to set. Mention rate limits early enough that developers do not get surprised by a 429 on their first few test calls. </constraints> <format> Return the guide as numbered steps, with a short code block showing the expected successful response at the end. </format>

You are an API product manager who communicates breaking changes to a developer base ahead of a version deprecation. <context> We are deprecating v1 of our API in favor of v2 and I need documentation that tells existing integrators exactly what breaks and how to migrate. </context> <inputs> - Old version: [E.G. V1] - New version: [E.G. V2] - Specific changes: [LIST CHANGES, e.g. renamed field, removed endpoint, new required parameter] - Deprecation deadline: [DATE] </inputs> <task> Write a migration guide documenting each breaking change side by side with the old and new behavior, concrete before and after request or response examples, and a clear deadline statement. </task> <constraints> Order changes from most to least disruptive so integrators see the biggest risks first. Use a consistent before and after format for every change so it is scannable. State the deprecation deadline in at least two places, at the top and in a closing summary, since this is the detail people miss. </constraints> <format> Return a short intro paragraph, then one subsection per breaking change with before and after code blocks, ending with a closing summary that restates the deadline. </format>

You are an operations engineer who writes runbooks so on call staff can troubleshoot production issues using existing Postman requests. <context> When something breaks in production, our on call engineers do not know which saved Postman requests to run to diagnose the problem, and I want that documented before the next incident. </context> <inputs> - Relevant collection requests: [LIST REQUEST NAMES AND WHAT THEY CHECK] - Common incident scenarios: [LIST SCENARIOS, e.g. payments failing, auth service down] - Expected healthy response for each check: [DESCRIBE OR PASTE EXAMPLES] - Escalation contact or next step if the check fails: [DESCRIBE ESCALATION PATH] </inputs> <task> Write a runbook mapping each incident scenario to the specific Postman request an on call engineer should run, what a healthy response looks like, and what to do next if the response indicates a problem. </task> <constraints> Write for someone who is stressed and reading quickly during an incident, use short direct sentences and bold the key action in each step. Do not bury the escalation path, put it at the end of every scenario section. Avoid assuming deep familiarity with the system, this may be read by a engineer who is not the usual owner. </constraints> <format> Return one section per incident scenario with a bold heading, a numbered list of diagnostic steps, and an escalation line at the end of each section. </format>

You are a support engineer who turns recurring API support tickets into self service documentation. <context> Our support queue keeps getting the same handful of questions about this API and I want a FAQ section added to the Postman documentation to cut down repeat tickets. </context> <inputs> - Recent support questions: [PASTE OR LIST 5 TO 10 REAL QUESTIONS] - Correct answers to each: [PROVIDE ANSWERS, EVEN ROUGH NOTES ARE FINE] - API name: [API NAME] - Tone preference: [FORMAL / CASUAL / TECHNICAL] </inputs> <task> Rewrite each support question into a clear FAQ question and answer pair suitable for the Postman documentation tab, using the given tone, and group related questions together. </task> <constraints> Keep answers direct and specific, avoid vague phrasing that would generate a follow up question. If a rough note does not fully answer the question, flag it rather than inventing details. Group questions logically, for example all auth related questions together, rather than keeping the original ticket order. </constraints> <format> Return grouped FAQ sections with a bold question followed by its answer, and a final list of any answers that need more detail before publishing. </format>

You are a DevOps engineer who wires API test suites into continuous integration pipelines. <context> We have a Postman collection with working tests but it only runs manually, and I need it running automatically on every pull request. </context> <inputs> - CI platform: [GITHUB ACTIONS / GITLAB CI / JENKINS / CIRCLECI] - Collection export location: [FILE PATH OR POSTMAN CLOUD LINK] - Environment file needed: [ENVIRONMENT FILE NAME] - Failure behavior wanted: [BLOCK MERGE ON FAILURE / WARN ONLY] </inputs> <task> Write the CI configuration file that installs Newman, runs the collection against the specified environment, and enforces the given failure behavior on the pipeline result. </task> <constraints> Use the exact syntax for the specified CI platform, do not give pseudocode. Include a step that publishes the Newman test report as a pipeline artifact so failures are easy to inspect. Keep secrets like API keys referenced from the CI platform's secret store, never hardcoded in the file. </constraints> <format> Return the complete CI configuration file in a code block, followed by a one line note on where to add the actual secret values in that platform's settings. </format>

You are a site reliability engineer who uses Postman Monitors to catch API issues before customers report them. <context> We do not currently have any automated uptime or health checking on this API and I want a monitor set up that actually catches real problems, not just a ping. </context> <inputs> - Endpoints to monitor: [LIST ENDPOINTS] - Business hours or traffic pattern: [DESCRIBE, e.g. 24/7 GLOBAL, BUSINESS HOURS EST] - Acceptable response time threshold: [THRESHOLD IN MS] - Alert destination: [EMAIL / SLACK / PAGERDUTY] </inputs> <task> Design a Postman Monitor configuration including run frequency, which regions to run from, the assertions each run should check beyond just a 200 status, and the alert routing rules for failures. </task> <constraints> Match run frequency to the traffic pattern given, do not default to a generic every 5 minutes without justifying it. Include at least one assertion beyond status code, such as response time or a key field check. Specify escalation logic if failures repeat, not just a single alert per failure. </constraints> <format> Return a short configuration summary table followed by a bullet list of the specific assertions to add to each monitored request. </format>

You are a QA automation engineer who runs the same Postman request across many data variations using Newman's data file feature. <context> I need to test one endpoint against dozens of input combinations and manually changing the request body each time is not sustainable. </context> <inputs> - Endpoint and request body template: [METHOD, PATH, AND BODY TEMPLATE] - Variables to swap per iteration: [LIST VARIABLES, e.g. userId, planType] - Sample data rows: [PASTE 5 TO 10 SAMPLE ROWS OR DESCRIBE THEM] - Expected outcome per row, if known: [DESCRIBE EXPECTED RESULTS] </inputs> <task> Produce a CSV or JSON data file matching the given variables and sample rows, the request body template updated to reference the data file variables using Postman's {{variable}} syntax, and a Tests tab script that checks the expected outcome per row where provided. </task> <constraints> Keep the data file format consistent, do not mix CSV and JSON in the same output. Reference variables in the request body exactly as Postman expects for data file iteration. If expected outcomes were only given for some rows, only assert on those and note which rows have no expected outcome yet. </constraints> <format> Return the data file content in a code block, the updated request body template, and the Tests tab script, each clearly labeled. </format>

You are a platform engineer who keeps a team's Postman collection automatically in sync with its source of truth OpenAPI spec. <context> Our OpenAPI spec is the source of truth but the Postman collection drifts out of date because updating it is a manual step people forget. </context> <inputs> - Spec file location: [FILE PATH OR URL] - Postman collection ID or workspace: [COLLECTION ID OR WORKSPACE NAME] - Sync tool available: [POSTMAN CLI / OPENAPI-TO-POSTMAN NPM PACKAGE / POSTMAN API DIRECTLY] - Trigger for the sync: [ON COMMIT TO MAIN / NIGHTLY SCHEDULE] </inputs> <task> Write the automation script or CI step that converts the current OpenAPI spec into a Postman collection and pushes it to the specified collection using the Postman API, triggered as specified. </task> <constraints> Use the actual available tool named in the input rather than assuming a different one. Include error handling so a malformed spec does not silently push a broken collection. Note that this will overwrite manual edits made directly in Postman and suggest how the team should handle that tradeoff. </constraints> <format> Return the automation script or CI step in a code block, followed by a short warning paragraph about the manual edit overwrite tradeoff. </format>

You are an engineering manager who is introducing automated API testing to a team that has only ever tested manually. <context> My team has never run automated API tests before and I need to introduce Newman and CI integration without disrupting current delivery timelines. </context> <inputs> - Team size: [NUMBER OF ENGINEERS] - Current testing process: [DESCRIBE CURRENT MANUAL PROCESS] - Existing Postman collection maturity: [E.G. FEW REQUESTS, NO TESTS / LARGE COLLECTION, SOME TESTS] - Timeline pressure: [DESCRIBE ANY DEADLINE CONSTRAINTS] </inputs> <task> Create a phased rollout plan for introducing automated Postman and Newman testing into the team's CI pipeline, starting from the current maturity level, including what to automate first and how to measure whether it is working. </task> <constraints> Respect the stated timeline pressure, do not propose a plan that requires weeks of upfront investment if the team is under a tight deadline. Start with the highest value, lowest effort tests first rather than trying to cover everything at once. Include a simple way to measure success, such as reduction in manual testing time or bugs caught before release. </constraints> <format> Return a phased plan with 3 to 4 phases, each with a one sentence goal, key actions, and a rough time estimate. </format>

You are an API troubleshooting specialist who helps developers figure out why a request is failing before they escalate to the backend team. <context> A request that used to work is now returning an error and I need to figure out if it is my request or a real API problem before I bother the backend team. </context> <inputs> - Request sent, including headers and body: [PASTE FULL REQUEST] - Response received, including status and body: [PASTE FULL RESPONSE] - What worked before, if known: [DESCRIBE PREVIOUS WORKING REQUEST OR WRITE UNKNOWN] - Recent changes on my side: [DESCRIBE ANY CHANGES OR WRITE NONE] </inputs> <task> Analyze the request and response together, identify the most likely cause of the error based on the status code and response body content, and state clearly whether this looks like a client side mistake or a server side issue. </task> <constraints> Base the diagnosis on the actual status code and error body given, not generic troubleshooting advice. If the response body contains a specific error message, quote it and explain what it implies. Give one clear next action, not a list of five possible things to try. </constraints> <format> Return a short diagnosis paragraph stating the likely cause, followed by one bolded recommended next action. </format>

You are a Postman power user who troubleshoots variable scoping issues that confuse newer users. <context> A variable in one of my requests keeps showing up as literally {{variableName}} instead of its actual value and I cannot figure out why. </context> <inputs> - Variable name in question: [VARIABLE NAME] - Where it is used, e.g. URL, header, body: [LOCATION IN REQUEST] - Current active environment: [ENVIRONMENT NAME] - Where I think it is defined: [COLLECTION VARIABLE / ENVIRONMENT VARIABLE / GLOBAL VARIABLE] </inputs> <task> Walk through Postman's variable scope resolution order to identify the most likely reason this specific variable is not resolving, given where the user believes it is defined and what environment is active. </task> <constraints> Explain the actual Postman scope precedence order, global, collection, environment, local, and data, so the user understands why this happened, not just how to fix it this one time. Give a specific check to run, such as looking in the environment quick look panel. Keep the explanation short, this is a quick fix not a tutorial. </constraints> <format> Return a 3 to 5 sentence explanation followed by one specific check to run to confirm the fix. </format>

You are a QA engineer who investigates flaky automated tests that pass locally but fail intermittently in CI. <context> Our Postman tests pass consistently when I run them manually but fail intermittently in the CI pipeline, and it is eroding trust in the test suite. </context> <inputs> - Test that fails intermittently: [TEST OR REQUEST NAME] - Failure pattern: [E.G. FAILS 1 IN 5 RUNS, FAILS ONLY AFTER OTHER TESTS] - CI environment differences from local: [DESCRIBE, e.g. PARALLEL EXECUTION, DIFFERENT NETWORK] - Sample failure output: [PASTE CI LOG OR ERROR MESSAGE] </inputs> <task> List the most likely causes of intermittent Postman or Newman test failures given the described pattern and environment differences, ranked by likelihood, and suggest a specific diagnostic step for the top two causes. </task> <constraints> Prioritize causes common to API test flakiness specifically, such as shared state between tests, timing dependent assertions, or environment variable collisions in parallel runs, over generic advice. Rank causes by likelihood given the actual failure pattern described, do not list them in arbitrary order. Keep the diagnostic steps concrete enough to run today. </constraints> <format> Return a ranked list of 3 to 5 likely causes, with a one line diagnostic step under the top two. </format>

You are an application security engineer who audits shared Postman collections before they get exported or made public. <context> We are about to share a Postman collection outside the team and I want to make sure it does not leak any secrets or sensitive data first. </context> <inputs> - Collection content or sample requests and variables: [PASTE SAMPLE REQUESTS AND VARIABLES] - Intended sharing scope: [INTERNAL TEAM / EXTERNAL PARTNER / PUBLIC] - Known sensitive systems this API touches: [LIST SENSITIVE SYSTEMS SUCH AS PAYMENTS OR PII] - Current variable handling approach: [DESCRIBE CURRENT VARIABLE HANDLING APPROACH] </inputs> <task> Review the given requests and variables for hardcoded secrets, tokens, or sensitive sample data that should not be shared at the intended scope, and list specific fixes such as converting variables to secret type or replacing real sample data with synthetic data. </task> <constraints> Flag anything that looks like a real credential, token, or personal data value specifically, not just a general reminder to be careful. Match the strictness of recommendations to the sharing scope, public sharing needs stricter fixes than internal sharing. Do not repeat the actual secret value back in your findings, reference it by field name instead. </constraints> <format> Return a table of findings with columns for location, risk, and recommended fix, ordered by severity. </format>

You are an experienced Postman user who reads console logs quickly to spot the actual problem buried in verbose output. <context> I opened the Postman console to debug a request and there is a wall of log output and I cannot tell what is actually relevant to my problem. </context> <inputs> - Console log output: [PASTE CONSOLE LOG] - What I expected to happen: [DESCRIBE EXPECTED BEHAVIOR] - What actually happened: [DESCRIBE ACTUAL BEHAVIOR] - Request type involved: [E.G. PRE-REQUEST SCRIPT, TEST SCRIPT, RAW REQUEST] </inputs> <task> Read through the console log and identify the specific lines that explain the gap between expected and actual behavior, ignoring routine log noise that is not relevant to this problem. </task> <constraints> Quote only the specific log lines that matter, do not repeat the entire log back. Explain in plain language what those lines mean for someone who is not deeply familiar with Postman's internal request lifecycle. If the log does not contain enough information to diagnose the issue, say so and state what additional log output would help. </constraints> <format> Return the relevant quoted log lines, followed by a short plain language explanation of what they indicate is going wrong. </format>