API Testing Checklist: Functional, Security & Performance (2026)

This checklist treats all three dimensions as mandatory, explains what each item actually catches, and links to a downloadable CI/CD-focused version for teams who want a printable reference alongside this full explanation.

In this guide

1. Functional Testing Checklist
2. Security Testing Checklist
3. Performance Testing Checklist
4. CI/CD Integration Checklist
5. How to Turn This Checklist into Automated Tests
6. Common Mistakes When Using a Checklist
7. Run the checklist as a script
8. The API testing checklist at a glance
9. Turning the checklist into a gate
10. Frequently asked questions about API testing

Functional Testing Checklist

• ✔ Every documented status code is tested, not just the success path — 200/201 for success, 400/422 for invalid input, 401/403 for auth failures, 404 for missing resources, 409 for conflicts.
• ✔ Response body matches the documented schema — field names, types, and nullability, not just "the JSON parses."
• ✔ Required vs. optional fields are distinguished — a request missing an optional field should succeed; missing a required one should return a clear 400.
• ✔ Error responses have a consistent, documented shape across every endpoint, not a different error format per controller.
• ✔ Pagination behaves correctly at boundaries — page 0, the last page, a page number past the end, and an empty result set.
• ✔ Idempotent operations are actually idempotent — retrying the same PUT or DELETE twice produces the same end state, not a duplicate or an error on the second call.
• ✔ Boundary and null-input cases are covered — empty strings, zero, negative numbers, maximum-length strings, and null where the field is nullable.
• ✔ Content-type negotiation is correct — the API returns the content type it claims (Content-Type header matches the actual body format) and rejects unsupported ones appropriately.

For the command-line half of the same job — reproducible one-liners, CI smoke checks and TLS debugging — see curl vs Postman.

Security Testing Checklist

• ✔ Every endpoint requires authentication, including ones that seem "internal" or low-risk — an unauthenticated endpoint is a common audit finding, not a hypothetical.
• ✔ Authorization is tested per-object, not just per-role. A logged-in user should not be able to fetch another user's resource by changing an ID in the URL — this is Broken Object Level Authorization (BOLA), the top item in the OWASP API Security Top 10 and one of the least-tested paths in typical suites.
• ✔ Injection payloads are rejected, not just malformed input — SQL, NoSQL, and command injection strings sent through every input field should fail safely, not execute.
• ✔ Rate limiting is enforced and returns the correct status. A burst past the limit should return 429 with a Retry-After header, not silently succeed or crash.
• ✔ No sensitive data leaks into responses — passwords, internal IDs, stack traces, or PII that the caller shouldn't see, especially in error responses during debugging.
• ✔ Expired and malformed tokens are rejected. A JWT past its expiry, with an invalid signature, or with an unexpected algorithm (none) should fail authentication, not degrade gracefully into an authenticated state.
• ✔ CORS and security headers are configured correctly for the API's actual consumers — neither wide-open (Access-Control-Allow-Origin: * on an authenticated API) nor so strict that legitimate clients break.
• ✔ Coverage is mapped against the OWASP API Security Top 10, not tested ad hoc — see the consolidated OWASP API Top 10 testing guide for a per-risk breakdown.

Performance Testing Checklist

• ✔ p95 (and ideally p99) latency is under your SLA for every critical endpoint — the average alone hides the tail latency real users experience.
• ✔ The API is load tested at expected peak concurrency, not just a smoke-test volume — see JMeter or k6 for how to build that suite.
• ✔ Timeout handling is verified explicitly — a slow downstream dependency should produce a defined timeout response, not hang the request indefinitely.
• ✔ Concurrent writes to the same resource behave correctly — two simultaneous updates to the same record should not silently lose one of them (a classic race-condition bug that functional tests run sequentially never catch).
• ✔ Payload size limits are enforced. An oversized request body should be rejected with a clear status, not crash the process or degrade unrelated requests.
• ✔ Cache headers are correct where caching is expected — Cache-Control, ETag, and conditional requests (If-None-Match) behaving as documented.
• ✔ The API degrades gracefully under load, ideally shedding load or queuing rather than returning 500s across the board once a threshold is crossed.
• ✔ No N+1 query regressions — a list endpoint's response time should not grow linearly with the number of items returned in a way that reveals a query executed per row.

CI/CD Integration Checklist

• ✔ Functional and basic security checks run on every pull request — fast enough (typically under 5–10 minutes) that they don't slow down normal development.
• ✔ A regression suite runs before merge to main, covering every endpoint, not a hand-picked subset.
• ✔ Load tests run on a schedule or gated to release branches, not every commit — see the CI/CD sections in the JMeter and k6 guides for the exact pipeline pattern.
• ✔ A failing security or functional check blocks the merge, not just posts a warning that gets ignored.
• ✔ Test reports are visible in the CI provider's UI — a failure that requires digging through raw logs to understand gets ignored under deadline pressure.

How to Turn This Checklist into Automated Tests

A checklist is a coverage map, not a substitute for automation — every item above should become an assertion that runs on every relevant change, not a manual pre-release ritual. Pick the framework that matches your stack:

• Python teams — see the pytest + requests tutorial for functional and schema-validation patterns.
• Java teams — see REST Assured or Karate.
• JavaScript/TypeScript teams — see Playwright or Cypress.
• Manual exploration first, then automation — see Postman for beginners.
• Load and performance specifically — see JMeter or k6.

Whichever framework you choose, the functional and security items in this checklist scale linearly with endpoint count — twice the endpoints means roughly twice the assertions to write and maintain by hand. Total Shift Left generates the functional and security-adjacent positive/negative/boundary cases directly from your OpenAPI spec, covering most of the functional and security columns above automatically, so your team's manual effort concentrates on the performance testing and business-logic edge cases a generator can't infer from the spec alone.

Common Mistakes When Using a Checklist

• Treating the checklist as a one-time pre-launch exercise instead of a living set of automated assertions that run on every change.
• Skipping the security and performance columns because they take longer to set up than functional checks — this is precisely the gap that produces production incidents.
• Testing authorization at the role level only, missing per-object checks (BOLA) that a role-based test alone can't catch.
• Never testing the error path, so a suite with 100% passing tests still ships an API that fails unpredictably on bad input.
• Running load tests so rarely that a regression ships between test runs — even a lightweight, infrequent load check is better than none.

Run the checklist as a script

The functional half of the checklist is mechanical enough to script, so it runs on every deploy instead of once a quarter:

#!/usr/bin/env bash
# smoke-checklist.sh — the non-negotiables, in about 20 seconds
set -euo pipefail
API=${1:?usage: smoke-checklist.sh https://staging.example.com}
T=${TOKEN:?export TOKEN first}
fail() { echo "FAIL: $*"; exit 1; }

# 1. unauthenticated requests are rejected
[ "$(curl -so /dev/null -w '%{http_code}' "$API/v1/orders")" = 401 ] || fail "no auth required"

# 2. the happy path returns the documented status
[ "$(curl -so /dev/null -w '%{http_code}' -H "Authorization: Bearer $T" "$API/v1/orders")" = 200 ] || fail "list orders"

# 3. invalid input is a 4xx, not a 500
[ "$(curl -so /dev/null -w '%{http_code}' -XPOST -H "Authorization: Bearer $T" \
     -H 'Content-Type: application/json' -d '{"qty":-1}' "$API/v1/orders")" = 422 ] || fail "validation"

# 4. errors use the documented problem+json shape
curl -s -XPOST -H "Authorization: Bearer $T" -H 'Content-Type: application/json' \
     -d '{"qty":-1}' "$API/v1/orders" | jq -e '.type and .title and .status' >/dev/null || fail "error shape"

# 5. security headers are present
curl -sI -H "Authorization: Bearer $T" "$API/v1/orders" \
  | grep -qi '^strict-transport-security' || fail "no HSTS"

echo "checklist passed"

The API testing checklist at a glance

Every item, when it runs, and what a failure actually means:

Turning the checklist into a gate

A checklist that lives in a document gets consulted before a release and forgotten between them. The version that holds is one where each item is either automated or explicitly waived, and the waiver is visible.

The practical form is a short manifest committed next to the suite: each checklist item, the test that covers it, and — where nothing covers it — a one-line reason and an owner. It takes an afternoon to write and it converts "we should test that" into either a test or a decision somebody made on purpose. Items with neither are the real finding, and they are invisible while the checklist stays prose.

Frequently asked questions about API testing

What should a complete API testing checklist cover? Three dimensions: functional correctness, security, and performance. A checklist that only covers functional checks misses the failure classes that actually cause incidents.

What is the most commonly skipped item on API testing checklists? Per-object authorization testing (BOLA) — a valid, authenticated user accessing another user's data by changing an ID. It's the top item in the OWASP API Security Top 10 and one of the least-tested paths in typical suites.

How do I test API error handling? Send invalid input deliberately and assert both the status code and that the error response has a consistent, documented shape.

Should performance testing be part of every API test suite? At minimum, a per-request latency assertion belongs in the functional suite. Dedicated load testing is a separate pipeline stage, but "does this respond fast enough" should never be skipped entirely.

How often should this checklist be run? Functional and basic security checks on every pull request; full load tests and deeper security scans on a schedule or before release.

Is a checklist enough, or do I still need automated tests? A checklist is a coverage map, not a replacement for automation — turn each item into an automated assertion so it runs on every change.

Sources and further reading

• OWASP API Security Top 10 (2023) — the reference list of API risk categories.
• RFC 9110 — HTTP Semantics — the normative definition of methods, status codes and headers.
• OpenAPI Specification — the normative spec for describing HTTP APIs.

Key takeaways

• A complete checklist has three columns: functional, security, and performance — not functional alone.
• BOLA (per-object authorization) is the single most commonly skipped security check despite being the top OWASP API risk.
• Error-path testing matters as much as the happy path — a suite that only tests valid input never proves the API fails predictably.
• p95/p99 latency, not the average, is what real users experience — test and gate on the tail, not just the mean.
• Functional and basic security checks belong in CI on every PR; load tests belong on a schedule.
• Every checklist item should become an automated assertion, not a manual pre-release ritual repeated by hand.

Where to go next

• Common API Security Vulnerabilities and How to Test Them — the full OWASP API Top 10 breakdown behind the security column above.
• JMeter API Load Testing Tutorial and k6 API Load Testing Tutorial — turning the performance checklist into a real suite.
• REST API Testing Best Practices — the broader practices this checklist distills into actionable items.
• Download the printable CI/CD checklist — a 25-point one-page version for teams who want it at hand during a release.

Automate This Checklist Instead of Re-Checking It by Hand

Every functional and security item above can be generated automatically instead of manually verified before each release. Total Shift Left imports your OpenAPI spec and generates positive, negative, and boundary test cases across the functional and security dimensions of this checklist for every endpoint — regenerated the moment your spec changes.

Start your free trial to see your checklist coverage generated automatically, or see plans and pricing if you're already evaluating.