Update to Postman
Snapshot Oct 26, 2026 · 18:05 UTC · version 0.5.0
Collection source: downloaded plugin package.
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.
Up to 3 plugins free · no card required.
All fields and original values.
Skill instructions
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...
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
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"...
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 JSONSKILL.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
[
{
"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
}
][
{
"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
"---\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"
"---\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