Testing ASP.NET Core Web API using Postman

Postman is still the most convenient way to exercise a Web API by hand — every HTTP method, headers, bodies, and saved collections you can rerun after each change. This walkthrough tests GET, POST, PUT, and DELETE against an ASP.NET Core Web API and reads the status codes you should expect from each.

Install Postman

Download Postman and install it. The free tier does everything this tutorial needs.

Worth knowing alongside Postman:

• Since .NET 9 the Web API template ships an OpenAPI document, and viewers like Scalar give you an in-browser tester with zero setup — see getting started with ASP.NET Core Web API.
• Visual Studio and VS Code understand .http files (the template creates one), which keep runnable requests in your repository.

Postman remains the tool of choice when you want collections, environments, auth flows, and test scripts.

Create the ASP.NET Core Web API

Any API with CRUD endpoints works. The examples below use a supplier API like the one from CRUD operations using ASP.NET Core; run it with dotnet run and note the port Kestrel prints — requests go to http://localhost:<port>/api/supplier.

Test HTTP GET

In Postman, the left pane holds your history and collections; the right pane builds requests.

Select GET from the method dropdown, enter the API URL (http://localhost:<port>/api/supplier), and click Send. The response appears below — status 200 OK, body in JSON by default (the response viewer can also render XML, HTML, or plain text).

Test HTTP POST

POST creates a new entity; the API binds the JSON request body to the model ([FromBody]).

1. Select POST from the dropdown.
2. Enter the URL: http://localhost:<port>/api/supplier
3. Open the Body tab → choose raw → set the type to JSON.
4. Enter the supplier JSON object.
5. Click Send.

A successful create returns 201 Created, and the response body carries the created entity — including its server-generated id. Well-behaved APIs also return a Location header pointing at the new resource; check the Headers tab of the response.

Test HTTP PUT

PUT updates an entity (or, in some API designs, creates it at a known URL). The practical difference between PUT and POST: PUT is idempotent — sending the same PUT five times leaves the same single result, while sending the same POST five times creates five entities. A PUT request carries the complete entity with all attributes set; for partial updates APIs use PATCH.

1. Select PUT.
2. Enter the URL including the id: http://localhost:<port>/api/supplier/1
3. Body → raw → JSON, with the full updated supplier object.
4. Click Send.

A successful update returns 200 OK with content (this API responds "Supplier Updated Successfully."), or 204 No Content when the API returns an empty body. If the id doesn't exist, expect 404 Not Found.

Test HTTP DELETE

DELETE removes the entity addressed by the URL. If a DELETE request has a body, the server ignores it — the id in the URL is what matters.

1. Select DELETE.
2. Enter the URL with the id: http://localhost:<port>/api/supplier/1
3. Click Send.

Expected status codes:

• 200 OK — deleted, response includes content describing the result (this API's case).
• 204 No Content — deleted, empty response body.
• 404 Not Found — no entity with that id.

Tips that pay off quickly

• Save requests into a collection — after any API change, rerun the whole collection in order (GET → POST → GET → PUT → DELETE) as a manual regression pass.
• Use an environment variable for the base URL ({{baseUrl}}/api/supplier) so switching between local and deployed APIs is one dropdown.
• Watch the status code first, body second — most API bugs announce themselves in the code (400 model validation, 404 routing, 415 missing Content-Type: application/json, 500 server fault).
• If a request works in Postman but fails from a browser app, that is almost always CORS — Postman ignores CORS; browsers enforce it.