API Inspector User Manual

Welcome to API Inspector, a modular API testing and analysis tool designed for developers and QA engineers.

Request view

Installation

Requirements

Installer uses Inno Setup modern wizard style installation. The installer will automatically install the .NET 9 runtime if necessary.

Core Command‑Line Options Sysadmins Commonly Use

Silent / Unattended Installation

Silent install (no UI):

setup.exe /silent

Very silent (no UI, no progress window):

setup.exe /verysilent

Suppress reboot:

setup.exe /norestart

Force reboot if needed:

setup.exe /restart

Exclude desktop icon

setup.exe /TASKS="!desktopicon"

Override installation directory:

setup.exe /DIR="C:\Tools\API_Inspector"

Override Start Menu folder:

setup.exe /GROUP="API Tools"

Log installation

setup.exe /LOG="C:\Logs\api_inspector_install.log"

Silent uninstall:

"C:\Program Files\API_Inspector\unins000.exe" /silent

This example installs API Inspector silently, adds it to PATH, and logs the process:

API_Inspector_Setup.exe /verysilent /norestart 
 /TASKS=addtopath /LOG="C:\Logs\api_inspector.log"

Quick Start

  1. Create a new project folder.
  2. Launch API Inspector.
  3. Enter your credentials.
  4. Send an example request.
  5. Add assertions for the request.
  6. Set the working folder.
  7. Save your tests.
  8. You should now have test1.json and credentials.json in the working folder.

Application Sections

Request Editor

Request view

The Request Editor includes:

The Request view contains a dropdown for selecting the HTTP method, a textbox for the URL, and a Send button.
The result textbox shows the returned content or any error message.
The body textbox is used for requests that include a payload, such as POST.

HTTP Methods Summary

An operation is idempotent if applying it multiple times has the same effect as applying it once.

Log View

Request view

The Log View contains:

Logs can grow large and difficult to navigate, so several features help keep them manageable:

Assertions

Request view

You can create simple assertion tests without coding.
To test a JSON value, use:

$.value equals expectedValue

You can add multiple assertions per request to validate different parts of the response. Typical checks include:

If an assertion fails, the test is marked as failed and the failure is shown in test results/logs.

Headers

Request view

Use Headers to add key/value metadata to the request.

Common examples:

Notes:

Query Params

Request view

Query parameters are appended to the URL after ? and are used to filter or control results.

Example:

Rules:

Test Explorer

Allow you to run all tests. Including subfolders ones.

Request view

Test Explorer scans the working folder and subfolders for saved test files. From this view you can:

Use this view to validate large test sets in one action before committing changes.

Authorisation

Request view

You can change authorisation settings here.
Settings are saved in the working folder in a file called credentials.json.

Typical use:

Keep credentials.json secure and avoid committing sensitive values to source control.

Settings

Request view

The Settings view allows you to customise the behaviour of the application.

Examples of configurable behaviour include:

Settings are intended to persist your preferred workflow between sessions.

Tools

Paste-Response Mock API server

Request view

The Paste-Response Mock API server lets you quickly spin up a mock endpoint from any HTTP response you already have—perfect for front‑end development, demos, and debugging when the real backend is unavailable or unstable.

HAR Import / Export (HTTP Archive 1.2)

API Inspector supports HAR import/export for interoperability with browsers and external tools.

Use cases:

How to use:

Behavior details:

Compatibility:

API Inspector Test Endpoints

A set of lightweight httpbin‑style echo services for testing HTTP clients, debugging requests, and validating API behavior.

https://apiinspector.net/api/headers

Returns the exact headers sent by the client.

Example response:

{
  "headers": {
    "User-Agent": "API Inspector/0.7.0.2",
    "X-Test": "123"
  }
}

https://apiinspector.net/api/status/{code}

Returns a response with the HTTP status code you request.

/api/status/200 → 200 OK

/api/status/404 → 404 Not Found

/api/status/500 → 500 Internal Server Error

Redirect codes (301, 302, 307, 308) return a JSON message instead of performing a redirect, making them safe for testing.

https://apiinspector.net/api/anything

Echoes everything about the incoming request:

{
  "method": "POST",
  "path": "/api/anything/test?x=1",
  "subpath": "test",
  "args": { "x": "1" },
  "headers": { ... },
  "cookies": { },
  "body": "{\"hello\":\"world\"}",
  "json": { "hello": "world" },
  "form": [],
  "files": []
}

Perfect for debugging clients, verifying serialization, and inspecting raw requests.

API Inspector Command Line Tool

Request view

A command-line version of the API Inspector that allows you to execute API tests from .api files.

Features

  1. Search for API files - Recursively searches for *.api files in a directory
  2. Load credentials - Loads credentials from credentials.json in the search directory or AppData
  3. Execute tests - Runs tests defined in each API file
  4. Log output - Writes detailed logs to the current directory with timestamps
  5. Display results - Shows test execution summary and returns appropriate exit codes
  6. Exit codes:
    • 0 - All tests passed
    • 125 - One or more tests failed
    • 1 - Fatal error

Usage

Inspector [searchPath]

Arguments

Examples

Run tests in current directory:

Inspector

Run tests in a specific folder:

Inspector "C:\Tests\Api"

Use the CLI in CI/CD pipelines and check the process exit code to fail builds when tests fail.

REST API Design Rules

This chapter defines the core principles every API in your ecosystem must follow. These rules ensure long-term maintainability, predictable behavior, and a consistent developer experience.

1. Consistent Resource Naming

Resource naming must be predictable and uniform across the entire API.

Use nouns, plural, lowercase Prefer flat structures (/users//orders), avoid deep nesting Never use verbs (/getUsers, /createOrder) Keep naming conventions consistent across all services

Examples

/users
/users/{id}
/users/{id}/orders
/orders/{id}/items

2. Version from Day One

Versioning is a contract. Breaking changes require a new version.

3. Proper Status Codes

Status codes must accurately reflect the outcome of the request. HTTP Status Codes are defined in RFC 9110 Common essentials:

Never return 200 with an error payload.

4. Pagination from the Start

Collections must be paginated from day one to avoid breaking clients later. Supported strategies:

Example response:

{
  "data": [...],
  "meta": {
    "cursor": "abc123",
    "next_cursor": "def456"
  }
}

5. DTOs, Not Your DB Schema

Your API contract must be stable. Your database schema will change.

6. Rate Limiting

Protect your API and ensure fairness.

7. Design for Idempotency

Clients must be able to retry safely.

8. Standardized Errors

Errors must be machine-readable and consistent across all services. Recommended envelope

{
  "error": {
    "code": "user_not_found",
    "message": "User does not exist",
    "details": {},
    "request_id": "abc-123"
  }
}

Follow RFC 9457-style problem details when possible. You can read more about JSON RFC 8259 and JSON Pointers RFC 6901

9. Proper Auth Patterns

Security must be consistent and predictable.

10. Document Your API

Documentation is part of the product.

Use OpenAPI 3.1

11. Health Check Endpoints

Health checks must be lightweight and fast.

12. Observability from Day One

You cannot fix what you cannot see. Include:

13. Caching Strategy

Caching improves performance and reduces load.

14. Consistent Field Naming

Pick one style and stick to it across all services.

15. Soft Deletes vs Hard Deletes

Define deletion semantics clearly.

16. Timeouts & Retries

Define server-side timeouts and client retry rules.

17. Avoid Breaking Changes

Breaking changes require a new version. Avoid:

A consistent response envelope simplifies client logic. Example

{
  "data": {...},
  "meta": {...}
}

19. Security Headers

All APIs must include modern security headers.

20. Deprecation Policy

Define how and when endpoints are deprecated.

More reading

Version History and Updates

0.9 - 23.8.2026 POCO C# Generator — Generate clean C# models directly from API responses. Mock API Server — Spin up lightweight mock endpoints for testing and prototyping. Save Response — Persist any response for later inspection or comparison. OAuth Support — Full OAuth2 + PKCE flow handling with local callback listener. Highlight Toggle — Quickly switch syntax highlighting on/off. Idempotency Key Support — Automatically send and manage idempotency keys for safe retries. Updated to .NET 10.0 — Faster runtime, improved language features, and better performance across the app.

0.8 - 20.6.2026 Added: Data tests Added: HMAC tool Added: You can now popup windows Added: HAR import/export Added: More delete buttons for easy removal Logs names are now using PIDs

0.7 - 31.5.2026

0.6 - 6.5.2026

0.5 - 19.4.2026

0.4 - 25.3.2026

0.3 - 25.2.2026

0.2 - 4.1.2026

0.1 - 20.11.2025