Test the Diskarte REST API

Use Diskarte's OpenAPI spec and Postman collection to test both auth paths.

Introduction

30 Second Summary

A successful result can feel reassuring even when an important input is missing. Clear failures make hidden setup gaps much easier to fix.

In this project, you will use Postman CLI to run a local Postman Collection that sends a real HTTP request to Postman Echo. The same smoke test moves from one planned assertion failure to a clean pass after you inject a fake API-key value from Windows PowerShell.

What You'll Build

You will watch one request return a successful response while a missing-variable assertion stays red, then rerun the unchanged collection and see every assertion pass.

By the end of this project, you'll have:

  • A local API smoke test that reaches Postman Echo without a Postman account or cloud workspace.
  • A visible red-to-green test cycle that separates a successful request from missing runtime configuration.
  • A credential-free injection pattern that supplies a fake API-key value without saving it in the collection.
  • Secret Mission: Add a simulated bearer token with a second runtime variable and a third assertion.

Are there any prerequisites?

You need a Windows computer with internet access.

No Postman account or Diskarte repository is required. The lab uses fake training values, so your real Diskarte credentials stay out of every command.

Before We Start

Before the hands-on work begins, lock in what this credential-free rehearsal proves and why fake runtime values keep your real credentials out of the lab.

Install Postman CLI

Your credential-free rehearsal needs a maintained local runner before the collection can prove anything. Postman CLI sends collection requests from the terminal.

This step installs release 1.73.0 in Windows PowerShell. A version check gives you a dependable pass-or-fail signal before you build the collection.

Why Use Postman CLI?

Postman identifies Postman CLI as its preferred command-line collection runner. Newman is no longer maintained.

In this step, get ready to:
  • Confirm that Windows PowerShell is running as a normal user.
  • Install Postman CLI with the official Windows installer.
  • Verify that Postman CLI reports version 1.73.0.
Open Windows PowerShell

The installer belongs in a normal user session. This keeps the setup aligned with the PowerShell session you use throughout the lab.

  • Press the Windows key to open Windows search.
  • Type Windows PowerShell.
  • Press Enter to open Windows PowerShell.

You should see a standard PowerShell prompt. The window title should not indicate that it is running with administrator privileges.

Install Postman CLI

The official installer downloads the current Postman CLI binary for Windows. An active internet connection lets PowerShell retrieve the installer.

  • Install Postman CLI by running this official Windows installer command:
powershell -NoP -NonI -c "irm https://dl-cli.pstmn.io/install/win64.ps1 | iex"

What Does This Command Do?

This command retrieves Postman's official Windows installation script. PowerShell executes that script to install the Postman CLI binary.

When the script finishes, control returns to your PowerShell prompt. The version check in the next substep confirms that the installation succeeded.

Installer Did Not Finish?

  • Confirm that your internet connection is active.
  • Copy the official installer command again to remove any typing mistakes.

Help me troubleshoot the Postman CLI installation. You can also share the non-secret installer output in the NextWork community.

Verify the installed version

A fresh PowerShell session picks up the command location added by the installer. Reopening PowerShell removes an old session from the check.

  • Close the current PowerShell window.

The installer session is now closed.

  • Press the Windows key to open Windows search.
  • Type Windows PowerShell.
  • Press Enter to reopen Windows PowerShell.

Before you check, what version do you expect Postman CLI to report?

  • Check the installed Postman CLI version by running:
postman --version

What Does This Command Do?

Postman CLI prints its installed release number in the terminal. This gives you a direct check that PowerShell can find the command.

✔️ I see version 1.73.0

You've cleared the setup hurdle. Postman CLI 1.73.0 is installed and responding in PowerShell.

ⓧ I see another version

The CLI is present. Its release does not match this lab's verified 1.73.0 release.

  • Run the official Windows installer again to install the current release:
powershell -NoP -NonI -c "irm https://dl-cli.pstmn.io/install/win64.ps1 | iex"

Why Run the Installer Again?

The official installer retrieves the current Postman CLI binary. Running it again replaces the older release available to PowerShell.

  • Close PowerShell after the installer returns to the prompt.
  • Reopen Windows PowerShell from Windows search.
  • Check the updated version by running:
postman --version

What Does This Check Confirm?

The command prints the binary version available in the fresh PowerShell session. You should now see 1.73.0.

ⓧ Command not found

PowerShell cannot locate Postman CLI in the fresh session. The installation needs another pass.

  • Run the official Windows installer again:
powershell -NoP -NonI -c "irm https://dl-cli.pstmn.io/install/win64.ps1 | iex"

What Happens During This Retry?

PowerShell retrieves Postman's official Windows installation script again. The script installs the CLI binary on your machine.

  • Close PowerShell after the installer returns to the prompt.
  • Reopen Windows PowerShell from Windows search.
  • Check whether PowerShell can now find Postman CLI by running:
postman --version

What Does Success Look Like?

The command should print 1.73.0. That output confirms that the installation and command location are both available in the new session.

Still Not Seeing Version 1.73.0?

  • Confirm that every older PowerShell window was closed before you opened the latest session.
  • Rerun the installer command from the previous substep in a normal user session.

Help me get Postman CLI 1.73.0 responding in PowerShell.

Your local collection runner is ready. Next, you'll build a smoke test that reaches Postman Echo and exposes a missing runtime variable.

Create a Failing Smoke Test

Your Postman CLI runner is ready. The next risk is mistaking a successful HTTP response for a healthy smoke test.

In this step, you'll build a local collection that calls Postman Echo. Separate assertions check the response status and runtime configuration.

In this step, get ready to:
  • Save a local Collection v2.1 file.
  • Identify the request components and post-response tests.
  • Interpret the collection's baseline run.
Create the collection file

A Postman collection uses the Collection v2.1 JSON schema to describe requests and test scripts. The file keeps the request definition beside its checks.

  • Switch back to the Windows PowerShell session from the previous step.
  • Create the Desktop lab folder and move into it by running these commands:
Set-Location -Path "$HOME\Desktop"
New-Item -Path ".\postman-smoke-test" -ItemType Directory
Set-Location -Path ".\postman-smoke-test" -PassThru

What do these commands do?

  • The first Set-Location command moves your PowerShell session to the Desktop.
  • The New-Item command creates the postman-smoke-test folder.
  • The final Set-Location command enters the new folder. The -PassThru flag prints its path.

PowerShell prints a path ending in Desktop\postman-smoke-test. This confirms that later commands run beside the collection file.

Can't create the lab folder?

  • Check that your user profile contains a Desktop folder.
  • Confirm that every folder name in the commands uses the same spelling.

Help me create the lab folder in Windows PowerShell.

  • Press the Windows key to open Windows search.
  • Type Notepad into the search field.
  • Select Notepad from the results.
  • Select the full-code reference tab below.

✔️ Awesome, I've got everything!

Keep this tab for your final comparison. Use the adjacent tab now to copy the supplied collection.

ⓧ I'd like to double check the full code

{
  "info": {
    "name": "Windows API Smoke Test",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "item": [
    {
      "name": "Echo simulated API key",
      "event": [
        {
          "listen": "test",
          "script": {
            "type": "text/javascript",
            "exec": [
              "pm.test(\"Status test\", function () {",
              "    pm.response.to.have.status(200);",
              "});",
              "",
              "pm.test(\"Demo API key is configured\", function () {",
              "    pm.expect(pm.variables.has(\"demo_api_key\")).to.equal(true);",
              "});"
            ]
          }
        }
      ],
      "request": {
        "method": "GET",
        "header": [
          {
            "key": "X-Api-Key",
            "value": "{{demo_api_key}}"
          }
        ],
        "url": "https://postman-echo.com/get?source=windows-lab"
      },
      "response": []
    }
  ]
}

What does this collection do?

  • The info object names the collection and declares its Collection v2.1 schema.
  • The request sends GET to https://postman-echo.com/get?source=windows-lab with an X-Api-Key header.
  • The test script checks for status 200 and the runtime variable named demo_api_key.
  • Copy every line from the full-code reference.
  • Paste the collection into Notepad.
  • Click File in Notepad.
  • Click Save As.
  • Choose Desktop\postman-smoke-test as the destination folder.
  • Enter "my_collection.json" in the File name field.
  • Select UTF-8 from the Encoding field.
  • Click Save.
  • Switch back to the PowerShell session from earlier.
  • Confirm that the collection file exists by running this command:
Get-ChildItem -Path .\my_collection.json

You'll see my_collection.json listed with a size greater than zero. That's your test contract in place: the local smoke test is ready to inspect.

Can't find the collection file?

  • Check that your PowerShell path ends in Desktop\postman-smoke-test.
  • Return to Notepad if the filename ends in .json.txt. Save it again with "my_collection.json" as the filename.

Help me find my saved collection file.

Inspect the request and assertions

The collection is the smoke test contract. Reading it once shows which result comes from the endpoint and which result comes from runtime configuration.

  • Read my_collection.json once from top to bottom in Notepad.
  • Locate the request URL https://postman-echo.com/get?source=windows-lab.
  • Locate the X-Api-Key header with the {{demo_api_key}} placeholder.
  • Locate the test named Status test.
  • Locate the test named Demo API key is configured.

How do the two tests divide responsibility?

The Status test assertion checks whether Postman Echo responds with status 200. This establishes endpoint availability.

The Demo API key is configured assertion checks whether demo_api_key exists at runtime. This exposes missing configuration even when the endpoint responds.

Run the designed failure

A useful smoke test checks both the request and its assertions. This first run uses the collection exactly as saved so the terminal summary reveals its starting state.

Before you run this, do you think a 200 response guarantees that both assertions pass?

  • Run the local collection from the PowerShell session by entering this command:
postman collection run .\my_collection.json

This failure is intentional

  • The postman collection run command loads the local collection file and sends its GET request.
  • The request reaches Postman Echo and returns HTTP status 200.
  • The Status test assertion passes.
  • The Demo API key is configured assertion fails because demo_api_key is absent.
  • The terminal summary reports one failed assertion.

That is a useful result: your collection reaches the API while refusing to hide missing runtime configuration.

Don't see the planned result?

  • Confirm that the PowerShell path ends in Desktop\postman-smoke-test if the CLI cannot find the collection.
  • Check your internet connection if the request cannot reach Postman Echo.
  • Compare my_collection.json with the full-code reference if the assertion names differ.

Help me reproduce the planned Postman CLI result.

Your smoke test now catches missing runtime configuration without using a real credential. Next, you'll supply safe per-run configuration and turn the same collection green.

Inject the API Key Variable

Your first collection run reached Postman Echo with an HTTP 200 response. The missing demo_api_key still left one assertion red.

This step supplies a fake API key to Postman CLI at runtime. The failed assertion should turn green without changing the collection.

Windows PowerShell passes the value only to this run. Your my_collection.json file remains credential-free.

In this step, get ready to:
  • Inject a fake API key as a runtime variable.
  • Compare the passing summary with the earlier failed run.
  • Confirm the fake value was not stored in the collection.
Inject the fake API key

The --env-var option supplies configuration in key=value format for one collection run. The value resolves the {{demo_api_key}} placeholder without being written to the collection.

Before you run this, do you expect the HTTP result, the assertion result, or both to change?

  • Run the unchanged collection with the fake runtime value by entering this command:
postman collection run .\my_collection.json --env-var "demo_api_key=training-key"

How Does the Override Work?

The override creates demo_api_key for this run. Postman CLI uses training-key to resolve the collection placeholder.

The value is deliberately fake. This keeps the rehearsal separate from your real credentials.

You'll see the request return HTTP 200 again. The endpoint remains reachable.

The summary now shows Status test and Demo API key is configured as passing. It reports no failed assertions.

Still Seeing a Failed Assertion?

  • Check that your PowerShell prompt is inside the lab folder containing my_collection.json.
  • Check that the override contains demo_api_key=training-key.
  • Check that the command keeps the override inside double quotes.

Help me diagnose why the runtime variable assertion still fails.

Compare the run summaries

The two runs used the same request and tests. Their different assertion results isolate runtime configuration as the cause of the earlier failure.

  • Scroll up in PowerShell to locate the summary from the earlier run.
  • Compare the earlier Status test result with its result in the latest summary.
  • Compare the earlier Demo API key is configured result with its result in the latest summary.
  • Confirm that the latest summary reports two passing assertions.
  • Confirm that the latest summary reports no failed assertions.

You found the exact difference. The endpoint passed in both runs while the configuration assertion changed from failing to passing.

What Changed Between Runs?

The Status test proves that Postman Echo returned HTTP 200. The Demo API key is configured test proves that the runtime variable exists.

Together, these assertions separate endpoint availability from configuration readiness. The summary tells you which layer needs attention.

Confirm the collection stayed credential-free

Runtime injection should leave the collection contract untouched. A file check proves that training-key exists only in the PowerShell command.

  • Switch back to my_collection.json in the text editor you used earlier.
  • Find "value": "{{demo_api_key}}" in the request header.
  • Find pm.variables.has("demo_api_key") in the post-response test.
  • Press Ctrl+F to open the editor's search field.
  • Enter training-key in the search field.
  • Press Enter to search the file.

Your editor should report no match for training-key. The placeholder and variable-presence assertion remain unchanged.

✔️ Awesome, I've got everything!

Your collection still contains the runtime placeholder. The fake value remains outside the file.

ⓧ I'd like to double check the full code

{
  "info": {
    "name": "Windows API Smoke Test",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "item": [
    {
      "name": "Echo simulated API key",
      "event": [
        {
          "listen": "test",
          "script": {
            "type": "text/javascript",
            "exec": [
              "pm.test(\"Status test\", function () {",
              "    pm.response.to.have.status(200);",
              "});",
              "",
              "pm.test(\"Demo API key is configured\", function () {",
              "    pm.expect(pm.variables.has(\"demo_api_key\")).to.equal(true);",
              "});"
            ]
          }
        }
      ],
      "request": {
        "method": "GET",
        "header": [
          {
            "key": "X-Api-Key",
            "value": "{{demo_api_key}}"
          }
        ],
        "url": "https://postman-echo.com/get?source=windows-lab"
      },
      "response": []
    }
  ]
}
  • Return to PowerShell for the final verification.

Before the final run, do you expect the unchanged file to pass when the runtime override is supplied again?

  • Prove the unchanged collection still runs green by entering this command:
postman collection run .\my_collection.json --env-var "demo_api_key=training-key"

What Does This Final Run Prove?

The command supplies the missing value at execution time. The unchanged file still provides the request and both post-response tests.

A passing result proves that runtime configuration can fix the setup without embedding a credential value in the collection.

You'll see HTTP 200 with two passing assertions. The summary contains no failed assertions.

Final Run Does Not Match?

  • Compare my_collection.json with the full-code reference above.
  • Confirm that the command includes the demo_api_key=training-key override.
  • Confirm that PowerShell is still inside the lab folder.

Help me restore the two passing assertions.

That's the full red-to-green workflow complete. Your smoke test now passes with a fake runtime value while the collection remains credential-free.

Secret mission

Add a Simulated Bearer Token

Extend your smoke test with a simulated bearer token supplied only at runtime. You will expose a second planned configuration failure before injecting both fake authentication values for a three-assertion green run.

Clean Up Your Resources

Clean Up Your Resources

Your Postman CLI smoke test runs locally with no ongoing project costs. Choose whether to keep the collection available, pause your work, or delete the file.

Resources you used:

  • A local my_collection.json file containing the smoke test request plus its three assertions.

Keep everything running

No action needed. Choose this if you want to rerun the smoke test or reuse its runtime-injection pattern.

  • Keep my_collection.json in the folder open in Windows PowerShell.
  • Leave Postman CLI installed for future local collection runs.

Pause - I'll come back to this later

The collection run exits after printing its summary. No server or background process remains active.

  • Keep my_collection.json in its current folder.
  • Close the current PowerShell window.
  • Return to the same folder in PowerShell when you are ready to continue.

Delete - I don't want to use this again

This option gives you a clean start by removing the lab file. The deletion targets only my_collection.json, so your Postman CLI installation stays available.

  • Delete my_collection.json from the current PowerShell folder by running this command:
rm .\my_collection.json

What does this command do?

The command removes only my_collection.json from the folder shown in your current PowerShell prompt.

Your Postman CLI installation remains available for other projects.

  • Confirm that the collection file is gone by listing the current folder:
ls

What should I see?

The folder listing should no longer include my_collection.json. That absence confirms the lab file is gone.

Still seeing the collection file?

  • Check that the PowerShell prompt points to the folder where you saved my_collection.json.
  • Check that the filename is exactly my_collection.json.

Help me remove the remaining collection file.

Nice Work!

Nice Work!

You did it. Your credential-free Postman CLI smoke test now completes a real HTTP request with three passing assertions.

You've learned how to:

  • Built a local Postman Collection v2.1 smoke test that sends a real request to Postman Echo.
  • Used a designed failure to distinguish endpoint availability from missing runtime configuration.
  • Turned a failed assertion green by injecting a fake API-key value at runtime without embedding it in my_collection.json.
  • Secret Mission: Extended the request with a simulated bearer token to achieve three passing assertions while keeping both fake values out of my_collection.json.

Ready to quiz yourself?