← PostmanCONTENT HISTORY

Update to Postman

Snapshot Oct 26, 2026 · 18:05 UTC · version 0.5.0

Collection source: downloaded plugin package.

WHAT CHANGED

Instructions updated for performance-testing

Skill instructions — Now says: Import it by following `references/jmeter-import/README.md`, then treat the result as the collection above. Its mapping table carries the JMeter semantics...

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save Postman and check future changes in Following.

Up to 3 plugins free · no card required.

All fields and original values.

Skill instructions

Before

Oct 24, 2026 · 12:56 UTC

Don't rebuild it by hand — run the bundled importer (`references/jmeter-import/scripts/jmx_to_postman.py <plan>.jmx -o <out>`; see `references/jmeter-import/README.md`), then treat its output as the collection above. Read the generated r...

After

Oct 26, 2026 · 18:05 UTC

Import it by following `references/jmeter-import/README.md`, then treat the result as the collection above. Its mapping table carries the JMeter semantics that are easy to get wrong, and the import report marks what mapped exactly, what ...

Supporting files

Before

Oct 24, 2026 · 12:56 UTC

[{"relative_path":"references/jmeter-import/README.md","size_in_bytes":10581},{"relative_path":"references/jmeter-import/import-report.md","size_in_bytes":1843},{"relative_path":"references/jmeter-import/mapping-table.md","size_in_bytes"...

After

Oct 26, 2026 · 18:05 UTC

[{"relative_path":"references/jmeter-import/README.md","size_in_bytes":7579},{"relative_path":"references/jmeter-import/import-report.md","size_in_bytes":1859},{"relative_path":"references/jmeter-import/mapping-table.md","size_in_bytes":...

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -39,12 +39,12 @@
 
 ## Importing from JMeter
 
-Have a JMeter `.jmx` instead of a collection? Don't rebuild it by hand — run the
-bundled importer (`references/jmeter-import/scripts/jmx_to_postman.py <plan>.jmx
--o <out>`; see `references/jmeter-import/README.md`), then treat its output as the
-collection above. Read the generated report: it marks what mapped exactly, what
-was approximated, and which JMeter features have no equivalent here — think-time
-timers, concurrent thread groups, and non-HTTP (JDBC/FTP/LDAP/Java) samplers are
+Have a JMeter `.jmx` instead of a collection? Import it by following
+`references/jmeter-import/README.md`, then treat the result as the collection
+above. Its mapping table carries the JMeter semantics that are easy to get
+wrong, and the import report marks what mapped exactly, what was approximated,
+and which JMeter features have no equivalent here — think-time timers,
+concurrent thread groups, and non-HTTP (JDBC/FTP/LDAP/Java) samplers are
 reported, never faked.
 
 ## Verification
Full technical diff · 2 changed fields

changed /included_files

BEFORE
[
  {
    "relative_path": "references/jmeter-import/README.md",
    "size_in_bytes": 10581
  },
  {
    "relative_path": "references/jmeter-import/import-report.md",
    "size_in_bytes": 1843
  },
  {
    "relative_path": "references/jmeter-import/mapping-table.md",
    "size_in_bytes": 6823
  },
  {
    "relative_path": "references/jmeter-import/postman-perf-capabilities.md",
    "size_in_bytes": 3843
  },
  {
    "relative_path": "references/jmeter-import/script-translation.md",
    "size_in_bytes": 5899
  },
  {
    "relative_path": "references/jmeter-import/scripts/groovy_to_js.py",
    "size_in_bytes": 3867
  },
  {
    "relative_path": "references/jmeter-import/scripts/jmx_to_postman.py",
    "size_in_bytes": 65485
  }
]
AFTER
[
  {
    "relative_path": "references/jmeter-import/README.md",
    "size_in_bytes": 7579
  },
  {
    "relative_path": "references/jmeter-import/import-report.md",
    "size_in_bytes": 1859
  },
  {
    "relative_path": "references/jmeter-import/mapping-table.md",
    "size_in_bytes": 5921
  },
  {
    "relative_path": "references/jmeter-import/postman-perf-capabilities.md",
    "size_in_bytes": 3739
  },
  {
    "relative_path": "references/jmeter-import/script-translation.md",
    "size_in_bytes": 5709
  }
]

changed /skill_md_contents

BEFORE
"---\nname: performance-testing\ndescription: Use when load-testing or benchmarking an API with concurrent virtual users and latency or error thresholds. Reuses a collection to probe a chosen failure mode and distinguishes target limits from load-generator limits. Use for requests such as \"load test this API\".\n---\n\n# Performance Testing\n\nA collection supplies realistic request sequences; `postman performance run`\nadds concurrency and a load profile. This makes performance claims repeatable,\nbut only for the workload, data, and network path actually exercised.\nCollections run directly: converting with `postman-to-k6` is not required.\n\n1. Choose the failure mode before the profile: `fixed` tests sustained\n   concurrency, `ramp-up` explores degradation as load grows, `spike` tests\n   sudden surges, and `peak` tests staying near maximum load. Reuse the\n   collection's auth and assertions, and check that its operations and data\n   represent the workload rather than repeating one unusually cheap request.\n2. Establish the target, VU count, duration, and effects of write requests\n   before sending load. Existing user authorization for that scope is enough;\n   resolve missing limits before stressing a shared or production service.\n   Thresholds are evaluated after the run, so a failing gate will not stop\n   traffic early. A small initial run can expose wiring failures before a\n   larger authorized test.\n3. Choose the runner by reachability and capacity. `local` uses this machine\n   or CI runner; its CPU or network can become the bottleneck. `postman-cloud`\n   moves generation to Postman's infrastructure, while\n   `postman-cloud-static-ip` supports targets with IP allowlists. Verify\n   reachability before interpreting connection failures as service capacity.\n4. Set thresholds that represent the user's objective, such as\n   `--pass-if \"less_than(p95, 500)\"`. Supported metrics include `avg`, `p90`,\n   `p95`, `p99`, `error_rate`, and `rps`; latency alone can look good when\n   requests fail quickly. Use `postman performance run -h` for current syntax,\n   units, and runner-specific options.\n5. Isolate test data where concurrent writes would collide. **datasets**\n   supports controlled row distribution across VUs; setup/teardown collections\n   on hosted runners execute once around the test, not once per iteration.\n   `--use-mock` can baseline collection/script overhead, but its numbers\n   cannot establish the real backend's capacity.\n\n## Importing from JMeter\n\nHave a JMeter `.jmx` instead of a collection? Don't rebuild it by hand — run the\nbundled importer (`references/jmeter-import/scripts/jmx_to_postman.py <plan>.jmx\n-o <out>`; see `references/jmeter-import/README.md`), then treat its output as the\ncollection above. Read the generated report: it marks what mapped exactly, what\nwas approximated, and which JMeter features have no equivalent here — think-time\ntimers, concurrent thread groups, and non-HTTP (JDBC/FTP/LDAP/Java) samplers are\nreported, never faked.\n\n## Verification\n\nReport the workload, runner, achieved traffic, latency and error metrics,\nand threshold verdict. Identify generator limits or target errors that prevent\nattributing the result to API capacity. See **api-testing** for functional\nassertions and **ci-integration** when the measured threshold becomes a gate.\n"
AFTER
"---\nname: performance-testing\ndescription: Use when load-testing or benchmarking an API with concurrent virtual users and latency or error thresholds. Reuses a collection to probe a chosen failure mode and distinguishes target limits from load-generator limits. Use for requests such as \"load test this API\".\n---\n\n# Performance Testing\n\nA collection supplies realistic request sequences; `postman performance run`\nadds concurrency and a load profile. This makes performance claims repeatable,\nbut only for the workload, data, and network path actually exercised.\nCollections run directly: converting with `postman-to-k6` is not required.\n\n1. Choose the failure mode before the profile: `fixed` tests sustained\n   concurrency, `ramp-up` explores degradation as load grows, `spike` tests\n   sudden surges, and `peak` tests staying near maximum load. Reuse the\n   collection's auth and assertions, and check that its operations and data\n   represent the workload rather than repeating one unusually cheap request.\n2. Establish the target, VU count, duration, and effects of write requests\n   before sending load. Existing user authorization for that scope is enough;\n   resolve missing limits before stressing a shared or production service.\n   Thresholds are evaluated after the run, so a failing gate will not stop\n   traffic early. A small initial run can expose wiring failures before a\n   larger authorized test.\n3. Choose the runner by reachability and capacity. `local` uses this machine\n   or CI runner; its CPU or network can become the bottleneck. `postman-cloud`\n   moves generation to Postman's infrastructure, while\n   `postman-cloud-static-ip` supports targets with IP allowlists. Verify\n   reachability before interpreting connection failures as service capacity.\n4. Set thresholds that represent the user's objective, such as\n   `--pass-if \"less_than(p95, 500)\"`. Supported metrics include `avg`, `p90`,\n   `p95`, `p99`, `error_rate`, and `rps`; latency alone can look good when\n   requests fail quickly. Use `postman performance run -h` for current syntax,\n   units, and runner-specific options.\n5. Isolate test data where concurrent writes would collide. **datasets**\n   supports controlled row distribution across VUs; setup/teardown collections\n   on hosted runners execute once around the test, not once per iteration.\n   `--use-mock` can baseline collection/script overhead, but its numbers\n   cannot establish the real backend's capacity.\n\n## Importing from JMeter\n\nHave a JMeter `.jmx` instead of a collection? Import it by following\n`references/jmeter-import/README.md`, then treat the result as the collection\nabove. Its mapping table carries the JMeter semantics that are easy to get\nwrong, and the import report marks what mapped exactly, what was approximated,\nand which JMeter features have no equivalent here — think-time timers,\nconcurrent thread groups, and non-HTTP (JDBC/FTP/LDAP/Java) samplers are\nreported, never faked.\n\n## Verification\n\nReport the workload, runner, achieved traffic, latency and error metrics,\nand threshold verdict. Identify generator limits or target errors that prevent\nattributing the result to API capacity. See **api-testing** for functional\nassertions and **ci-integration** when the measured threshold becomes a gate.\n"
Full snapshot data
{
  "description": "Use when load-testing or benchmarking an API with concurrent virtual users and latency or error thresholds. Reuses a collection to probe a chosen failure mode and distinguishes target limits from load-generator limits. Use for requests such as \"load test this API\".",
  "included_files": [
    {
      "relative_path": "references/jmeter-import/README.md",
      "size_in_bytes": 7579
    },
    {
      "relative_path": "references/jmeter-import/import-report.md",
      "size_in_bytes": 1859
    },
    {
      "relative_path": "references/jmeter-import/mapping-table.md",
      "size_in_bytes": 5921
    },
    {
      "relative_path": "references/jmeter-import/postman-perf-capabilities.md",
      "size_in_bytes": 3739
    },
    {
      "relative_path": "references/jmeter-import/script-translation.md",
      "size_in_bytes": 5709
    }
  ],
  "name": "performance-testing",
  "skill_md_contents": "---\nname: performance-testing\ndescription: Use when load-testing or benchmarking an API with concurrent virtual users and latency or error thresholds. Reuses a collection to probe a chosen failure mode and distinguishes target limits from load-generator limits. Use for requests such as \"load test this API\".\n---\n\n# Performance Testing\n\nA collection supplies realistic request sequences; `postman performance run`\nadds concurrency and a load profile. This makes performance claims repeatable,\nbut only for the workload, data, and network path actually exercised.\nCollections run directly: converting with `postman-to-k6` is not required.\n\n1. Choose the failure mode before the profile: `fixed` tests sustained\n   concurrency, `ramp-up` explores degradation as load grows, `spike` tests\n   sudden surges, and `peak` tests staying near maximum load. Reuse the\n   collection's auth and assertions, and check that its operations and data\n   represent the workload rather than repeating one unusually cheap request.\n2. Establish the target, VU count, duration, and effects of write requests\n   before sending load. Existing user authorization for that scope is enough;\n   resolve missing limits before stressing a shared or production service.\n   Thresholds are evaluated after the run, so a failing gate will not stop\n   traffic early. A small initial run can expose wiring failures before a\n   larger authorized test.\n3. Choose the runner by reachability and capacity. `local` uses this machine\n   or CI runner; its CPU or network can become the bottleneck. `postman-cloud`\n   moves generation to Postman's infrastructure, while\n   `postman-cloud-static-ip` supports targets with IP allowlists. Verify\n   reachability before interpreting connection failures as service capacity.\n4. Set thresholds that represent the user's objective, such as\n   `--pass-if \"less_than(p95, 500)\"`. Supported metrics include `avg`, `p90`,\n   `p95`, `p99`, `error_rate`, and `rps`; latency alone can look good when\n   requests fail quickly. Use `postman performance run -h` for current syntax,\n   units, and runner-specific options.\n5. Isolate test data where concurrent writes would collide. **datasets**\n   supports controlled row distribution across VUs; setup/teardown collections\n   on hosted runners execute once around the test, not once per iteration.\n   `--use-mock` can baseline collection/script overhead, but its numbers\n   cannot establish the real backend's capacity.\n\n## Importing from JMeter\n\nHave a JMeter `.jmx` instead of a collection? Import it by following\n`references/jmeter-import/README.md`, then treat the result as the collection\nabove. Its mapping table carries the JMeter semantics that are easy to get\nwrong, and the import report marks what mapped exactly, what was approximated,\nand which JMeter features have no equivalent here — think-time timers,\nconcurrent thread groups, and non-HTTP (JDBC/FTP/LDAP/Java) samplers are\nreported, never faked.\n\n## Verification\n\nReport the workload, runner, achieved traffic, latency and error metrics,\nand threshold verdict. Identify generator limits or target errors that prevent\nattributing the result to API capacity. See **api-testing** for functional\nassertions and **ci-integration** when the measured threshold becomes a gate.\n"
}

SHA-256 of public snapshot: 42237decbac396ed239c7244067f9d545e9eae959555944f2822bff2be2dbcdd