How to Test REST API Requests and Debug Responses

Use a service you control and a test environment that cannot charge real customers. Record the method, full URL, content type, authentication requirements and body. Replace the illustrative origin below before running it.

Use an idempotency key only if the target service documents and implements it. The example token is a placeholder; configure credentials in the appropriate authentication control and avoid copying them into logs or screenshots.

POST https://api.example.com/payments
Content-Type: application/json
Authorization: Bearer <test-token>
Idempotency-Key: example-payment-003

{"amount":4900,"currency":"EUR"}

A synchronous payment creation may return 201 with Location and a JSON payment body. Compare that shape with the contract. A 2xx status does not prove the body has every required field. Treat these sample responses as expected behavior, not measured results.

For 401, inspect authentication; for 403, inspect permissions and scope. A 422 suggests semantically rejected input. A 409 can indicate a state conflict. Preserve safe request IDs for diagnosis without exposing tokens.

HTTP/1.1 201 Created
Content-Type: application/json
Location: /payments/pay_123

{"id":"pay_123","amount":4900,"currency":"EUR"}

Example validation response:
HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"code":"invalid_amount","message":"Amount must be positive"}

Browser Runner sends from your browser and is subject to CORS, TLS and browser network rules. A preflight failure may prevent the POST from being sent. Inspect the browser's Network panel and the target's allowed origin, method and headers.

Cloud Runner sends from the REST Test backend under its network protections. It cannot guarantee access to your private network and REST Test has no guaranteed static outbound IP. A cloud success therefore does not prove your browser frontend can reach the same endpoint.

First confirm the baseline. Then try a missing required field, amount: 0 and an unsupported currency in a test environment. Compare actual status and error shape to the contract, and record a discrepancy rather than editing the expectation to hide it.

Separate DNS, TLS, timeout and CORS failures from HTTP error responses. Honor Retry-After on 429 or 503 when present; do not retry payment creation blindly. A timeout can leave the outcome unknown even if the server completed the operation.

• Baseline: expected payment success.
• Missing or invalid credentials: authentication behavior.
• Known invalid input: documented domain error.
• Transport failure: connectivity diagnosis, not a JSON business error.

In REST Test, open an operation from Documentation in Request Builder, configure the test server and run it in the chosen execution context. Inspect the response and retained request history. For frontend error states without a backend, configure named mock variants and call the authenticated hosted runtime.

Request execution and response inspection are not an automated collection test runner. Use your application's tests for assertions, regression coverage and payment side-effect verification.