Answer.

Manual API testing is the process of verifying the operation of an application programming interface without automation, using specialized tools such as Postman, Swagger, or curl.

Background

Initially, APIs were tested manually due to the lack of automation and the relative simplicity of interfaces. Today, despite automation, manual testing remains relevant, especially for basic checks of new or unstable methods.

Problem

The main difficulties are associated with:

the need for a precise understanding of the structure of input and output data (JSON, XML, etc.)
the complexity of reproducing complex scenarios (authentication, system state dependencies)
the risk of missing hidden bugs that are not obvious through the UI

Solution

Successful testing requires:

careful work with the API documentation
creating sets of manual requests covering different parameters and error scenarios
testing both positive and negative scenarios (data validation, authorization checks)

Key features:

The ability to quickly check a new or modified endpoint without waiting for automated tests
Flexibility in analyzing anomalies and errors when the outcome is not obvious
Visual control over all stages of the request and response

Tricky questions.

Can manual API testing be performed using only the UI, without tools like Postman?

No, because many errors occur only at the data transfer level and are not reflected through the UI; specialized tools are necessary for comprehensive testing.

Is it enough to send only one valid request to check the API endpoint's operation?

No, it is important to test not only valid requests, but also all edge cases, invalid and rare scenarios; otherwise, bugs will go undetected.

Should negative scenarios be tested separately, or is it unnecessary work?

It is essential. It is important to ensure that the system correctly handles errors and rejects incorrect requests; otherwise, security and stability may be compromised.

Common mistakes and anti-patterns

Testing only "ideal" scenarios (no checks for invalid values)
Ignoring system state — checks with existing data or an unprepared database
Lack of validation for headers, error statuses, and non-standard cases

Real-life example

Negative case

The tester only checks a successful POST request to the API "create user" — sends a valid JSON, receives 200 OK, and considers the test complete.

Pros:

Quick check of the primary scenario

Cons:

Missed errors related to missing fields, incorrect email format, recreating the same user
No assurance that the API will return the correct error code

Positive case

The tester systematically checks the API "create user":

success for valid requests
errors for missing required parameters
an error when recreating
checks different HTTP codes, error messages, and email validation