From Theory to cURL: Real API Testing Examples for QA Teams

What Is an API, Explained With One Example?

An application programming interface (API) lets one piece of software request data or action from another without needing to know how that other system works internally. The clearest everyday example: when you log into a food delivery app using your Google account, the app sends a request to Google’s authentication API, Google verifies your identity, and it sends back a token confirming who you are. The delivery app never sees your Google password. It only sees the response.

That single exchange, a request out and a response back, is what every API test in this guide is built around.

What are Some Real-World API Examples?

APIs you interact with daily are also some of the best templates for practical test cases, since each one has a distinct failure mode worth checking.

These five patterns cover most of what a QA team encounters: authentication, geolocation, payment, identity, and content APIs. Every category below builds test cases directly on top of these patterns.

Scenario: verifying a login endpoint

1. Send a POST request with valid credentials to /login with a username and password.
2. Expect a 200 status code, a valid token in the response body, and correct token expiry.
3. Repeat the same request with an incorrect password.
4. Expect a 401 status code and an error message that does not reveal whether the username or the password was wrong.

That last step matters more than it looks. An error message that says “incorrect password” instead of a generic “invalid credentials” confirms a valid username exists, which is a small but real security leak.

Functional

• Submit malformed input, such as an invalid email format, and confirm the API rejects it with a clear message.
• Verify each supported HTTP method (create, read, update, delete) returns the correct response for that resource.
• Confirm the API returns the correct status code for each scenario, not just 200 for everything.
• Since a server won’t slow down or crash on command during an automated run, testers typically use a network proxy tool like ToxiProxy (or similar chaos-testing tools like WireMock’s fault injection or Gremlin) sitting between the API and its dependency to artificially inject latency, drop packets, or sever the connection, then observe whether the API times out cleanly with a proper error rather than hanging indefinitely.

Regression

• Run an automated suite against every build to confirm new changes have not broken existing endpoints.
• Test the API’s interaction with connected systems, not just the endpoint in isolation.

Usability

• Check that endpoint and parameter names follow one consistent naming convention across the whole API.

Performance

• Send a burst of parallel requests and measure how response time changes under load.
• Measure response time separately under normal and peak conditions, not just once.

Compliance

• Verify the API handles personal data in line with the privacy regulations that apply to it.
• Confirm the API follows the documented industry standard it claims to support.

• Input fuzzing: Send random, malformed, or oversized data into an endpoint and check whether it fails safely or throws an unhandled error that exposes internal details.
• Excessive data exposure: Check the raw API response, not just what the app displays, since a server that returns full user records for the client to filter on the front end is leaking data.
• Rate limiting: Send requests past the documented limit and confirm the API returns a 429 status code instead of continuing to process every call.
• Broken authorization: Confirm a standard user account cannot reach an admin-only endpoint or perform an admin-only action, regardless of resource ID — for example, a non-admin token hitting /admin/reports or calling a DELETE method the UI never exposes to that role.
• Broken Object Level Authorization (BOLA): Confirm a standard user account cannot access another user’s resource just by changing the ID in the request – for example, an authenticated user requesting /users/102 edits the URL or payload to /users/103 and checks whether the API returns that other user’s data instead of rejecting the request. BOLA is currently the #1 risk on the OWASP API Security Top 10, precisely because APIs often check that a user is authenticated but skip checking whether they’re authorized to access that specific object.

Broken authorization, excessive data exposure, and rate-limiting map directly onto the OWASP API Security Top 10; injection remains a core risk under OWASP’s general Top 10 web application risks.

These same test cases are the ones that matter most on any API called by something other than your own front end. If your team maintains a public or partner API, the most common API testing mistakes are a useful checklist to run before that surface goes live.

• JSONPlaceholder: free public REST API for basic, single-call CRUD testing – not built for multi-step transactions.
• ReqRes: persistent backend with custom endpoints for more realistic, stateful scenarios.
• DummyJSON: instant placeholder data with no server setup required.
• Beeceptor: simulates rate-limited APIs to test throttling behavior.
• Mocki: builds mock APIs with custom error scenarios and static responses.
• WireMock (via Docker): self-hosted mock server for stateful, multi-step transactions and fault injection that public mock sites can’t handle.

The Bottom Line

The gap between understanding API testing and actually doing it closes fast once you run a few real requests. Start with a sandbox or a dummy API, work through a login and a create-resource flow, then layer in the security test cases above before anything reaches production. For how to turn these individual examples into a program that scales across every endpoint you own, see the full API testing strategy guide, and for how the testing approach shifts across REST, SOAP, and GraphQL, see this breakdown of API types and protocols.

ACCELQ’s Autopilot can turn any of the examples above into an automated, repeatable test, from the login flow’s happy path to the security cases above, without writing the request scripts by hand.