Postman

Official

by postmanlabs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Update a collection request

updateCollectionRequest

Idempotent

Update an existing request in a Postman collection by modifying its URL, method, headers, body, auth, or scripts with a PATCH-style operation.

Instructions

Updates a request in a collection. For a complete list of properties, refer to the Request entry in the Postman Collection Format documentation.

Note:

You must pass a collection ID (`12ece9e1-2abf-4edc-8e34-de66e74114d2`), not a collection(`12345678-12ece9e1-2abf-4edc-8e34-de66e74114d2`), in this endpoint.
This endpoint does not support changing the folder of a request.
This endpoint acts like a PATCH method. It only updates the values that you pass in the request body.
Events (`events`). Events are merged by `listen` type, so you only need to send the event you are changing. A `listen` type you omit keeps its stored script. To empty a script, send its event with `script.exec` set to `[]` — sending `events: []` changes nothing.

Input Schema

Name	Required	Description
`url`	No	The request's URL.
`auth`	No	The request's authorization settings.
`data`	No	The request body's form or urlencoded data.
`name`	No	The request's name.
`events`	No	A list of scripts configured to run when specific events occur. Merged by `listen` type: send only the event you are changing, and any `listen` type you omit keeps its stored script. To empty a script, send its event with `script.exec` set to `[]`; sending an empty array changes nothing.
`method`	No	The request's HTTP method.
`dataMode`	No	The request body's data mode.
`requestId`	Yes	The request's ID.
`headerData`	No	The request's headers.
`dataOptions`	No	Additional options for the request body data.
`description`	No	The request's description.
`queryParams`	No	The request's query parameters.
`rawModeData`	No	The request body's raw mode data.
`collectionId`	Yes	The collection's ID.
`graphqlModeData`	No	The request body's GraphQL mode data.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.14.0Oct 21, 2026

changedInput schema / properties / events / description

Previous value: -"The request's pre-request and test scripts."New value: +"A list of scripts configured to run when specific events occur. Merged by `listen` type: send only the event you are changing, and any `listen` type you omit keeps its stored script. To empty a script, send its event with `script.exec` set to `[]`; sending an empty array changes nothing."

Changed4 schema fields changedv2.12.3Sep 9, 2026

changedInput schema / properties / auth / description

Previous value: -"The request's authentication information."New value: +"The request's authorization settings."

changedInput schema / properties / data / description

Previous value: -"The request body's form data."New value: +"The request body's form or urlencoded data."

changedInput schema / properties / dataOptions / description

Previous value: -"Additional configurations and options set for the request body's various data modes."New value: +"Additional options for the request body data."

changedInput schema / properties / events / description

Previous value: -"A list of scripts configured to run when specific events occur."New value: +"The request's pre-request and test scripts."

Changed3 schema fields changedv2.12.0Aug 19, 2026

removedInput schema / properties / events / anyOf

Removed value: -[
-  {
-    "items": {
-      "additionalProperties": false,
-      "properties": {
-        "listen": {
-          "description": "The event type.",
-          "enum": [
-            "test",
-            "prerequest"
-          ],
-          "type": "string"
-        },
-        "script": {
-          "additionalProperties": false,
-          "description": "Information about the Javascript code that can be used to to perform setup or teardown operations in a response.",
-          "properties": {
-            "exec": {
-              "description": "A list of script strings, where each line represents a line of code. Separate lines makes it easy to track script changes.",
-              "items": {
-                "type": [
-                  "string",
-                  "null"
-                ]
-              },
-              "type": "array"
-            },
-            "id": {
-              "description": "The script's ID.",
-              "type": "string"
-            },
-            "type": {
-              "description": "The type of script. For example, `text/javascript`.",
-              "type": "string"
-            }
-          },
-          "type": "object"
-        }
-      },
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / events / items

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "listen": {
+      "description": "The event type.",
+      "enum": [
+        "test",
+        "prerequest"
+      ],
+      "type": "string"
+    },
+    "script": {
+      "additionalProperties": false,
+      "description": "Information about the Javascript code that can be used to to perform setup or teardown operations in a response.",
+      "properties": {
+        "exec": {
+          "description": "A list of script strings, where each line represents a line of code. Separate lines makes it easy to track script changes.",
+          "items": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "type": "array"
+        },
+        "id": {
+          "description": "The script's ID.",
+          "type": "string"
+        },
+        "type": {
+          "description": "The type of script. For example, `text/javascript`.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / events / type
```
Added value: +"array"
```

Addedv2.8.7May 4, 2026

TDQS

A4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover readOnly=false, destructive=false, idempotent=true, so the safety profile is set; the description still adds substantial non-obvious behavior: omission keeps stored values, folder changes are unsupported, and events are merged by `listen` type with the `events: []` no-op gotcha. This is precisely the context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose in one sentence, then uses a scoped note with bullets for the exceptions. The link to the Request schema and the bullets all earn their place, though it is slightly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-param partial-update tool with full schema description coverage and no output schema, the description covers the key behavioral nuances (partial semantics, folder limitation, events merging). Only the absence of return-value or auth expectations keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the warning that a collection ID (not a collection) must be passed addresses the ambiguous `collectionId` param, and the `events` merge semantics are explained in depth.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Updates a request in a collection'), which clearly separates it from createCollectionRequest and other siblings. It lacks an explicit contrast, but the scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use it via the PATCH-like note ('only updates the values that you pass'), which tells an agent it is a partial update. However, it never names an alternative or states when-not-to-use this tool versus createCollectionRequest, so guidance stays implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Update a collection request

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools