View all services
Talk to QA Advisor
Browse the Knowledge Hub56 resources
/Test Cases/REST API test cases

Test cases

REST API test cases, including the ones that leak another tenant

Twenty eight cases covering status code correctness, PUT against PATCH semantics, unauthenticated against unauthorised, cross tenant resource access, mass assignment, idempotent retries, concurrent updates, cursor pagination, rate limits, error body consistency and contract drift.

28cases/8coverage types/9security cases/FreeCSV download

All 28 test cases, ready to copy

Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.

Last updated

28 worked examples

API-01

Create a resource with a valid payload

TypeFunctionalPriorityHigh
Test data
A complete valid body posted to the collection endpoint
Expected result
Status 201 with the created resource in the body, a Location header pointing at the new resource, and a server generated identifier the client did not supply.
API-02

Retrieve a resource that exists and one that does not

TypeFunctionalPriorityHigh
Test data
A known identifier, then an identifier that has never existed
Expected result
Status 200 with the resource, then 404 with a machine readable error body. A 200 carrying an empty object for a missing resource is a defect.
API-03

Distinguish a full update from a partial update

TypeFunctionalPriorityHigh
Test data
A PUT omitting an optional field, then a PATCH containing only that field
Expected result
PUT replaces the resource so the omitted field is cleared, PATCH modifies only what was sent. Treating PUT as a partial update silently keeps stale values.
API-04

Delete a resource and repeat the delete

TypeFunctionalPriorityHigh
Test data
DELETE a resource, then DELETE the same identifier again
Expected result
First returns 204 or 200. The second returns the documented outcome consistently, and repeating a delete never produces a 500.
API-05

Reject a payload that fails schema validation

TypeNegativePriorityHigh
Test data
A missing required field, a string where a number is expected, and an unexpected extra field
Expected result
Status 400 naming every failing field in one response rather than only the first, and the unknown field is rejected or ignored according to the documented contract.
API-06

Reject malformed JSON and the wrong content type

TypeNegativePriorityHigh
Test data
A truncated JSON body, then a valid body sent as plain text
Expected result
Status 400 for malformed JSON and 415 for the unsupported media type. Neither produces a 500 or an unhandled parser stack trace.
API-07

Distinguish unauthenticated from unauthorised

TypeSecurityPriorityHigh
Test data
No credential, an expired token, then a valid token lacking the required scope
Expected result
Status 401 for the first two and 403 for the third. Returning 403 for a missing credential tells the caller nothing about how to recover.
API-08

Refuse a resource belonging to another account

TypeSecurityPriorityHigh
Test data
Authenticate as one tenant and request a resource identifier owned by another
Expected result
Status 404 rather than 403, so existence is not disclosed. This is the single most common serious defect in a multi tenant API.
API-09

Refuse a write to another account resource

TypeSecurityPriorityHigh
Test data
PATCH and DELETE against a resource identifier owned by another tenant
Expected result
Both refused, and authorisation is evaluated per resource rather than only at the route. A read check that is not repeated on write is a common gap.
API-10

Ignore a client supplied field that must be server controlled

TypeSecurityPriorityHigh
Test data
A create payload including identifier, owner, role, balance and created timestamp
Expected result
Server controlled fields are ignored or rejected rather than accepted. Mass assignment of a role or owner field is a privilege escalation.
API-11

Perform a write once when the request is retried

TypeStatePriorityHigh
Test data
Send an identical create request twice with the same idempotency key
Expected result
One resource is created and the second call returns the original result. Without key support, every client side retry is a duplicate record.
API-12

Handle two concurrent updates to the same resource

TypeBoundaryPriorityHigh
Test data
Two PATCH requests changing different fields, sent at the same instant
Expected result
Both changes survive, or the later request is refused with 409 if the API uses optimistic concurrency. Neither change is silently lost.
API-13

Honour a conditional request with an entity tag

TypeFunctionalPriorityMedium
Test data
GET with a matching If-None-Match, then PATCH with a stale If-Match
Expected result
Status 304 for the unchanged read and 412 for the stale write, so a client cannot overwrite a resource it has not seen.
API-14

Paginate a collection consistently

TypeFunctionalPriorityHigh
Test data
Page through a collection while new records are being inserted
Expected result
No record is skipped or returned twice. Offset pagination shifts under insertion, so a cursor is required for a collection that changes.
API-15

Handle pagination boundaries and abusive page sizes

TypeBoundaryPriorityHigh
Test data
Page zero, a negative page, a page beyond the last, and a page size of 100,000
Expected result
Invalid values return 400, a page beyond the end returns an empty collection rather than 404, and page size is capped at a documented maximum.
API-16

Filter and sort by permitted fields only

TypeSecurityPriorityHigh
Test data
Sort by an unindexed internal column, and filter on a field the caller cannot read
Expected result
Refused with 400 against an allow list. Passing sort and filter parameters into a query unchecked is both an injection and a performance risk.
API-17

Enforce the rate limit and describe it

TypeSecurityPriorityHigh
Test data
Exceed the documented limit, then wait for the window to reset
Expected result
Status 429 with a Retry-After header, limit headers on normal responses, and the counter enforced per credential rather than per address alone.
API-18

Handle a payload at and above the size limit

TypeBoundaryPriorityMedium
Test data
A body at the documented maximum, then one byte above it
Expected result
Accepted then refused with 413. The connection is not dropped without a response, which is what makes this failure hard for a client to diagnose.
API-19

Return a consistent error body for every failure

TypeFunctionalPriorityHigh
Test data
Trigger a 400, a 401, a 404, a 409 and a 500
Expected result
Every error uses the same documented shape with a stable machine readable code. A 500 body never contains a stack trace, query text or internal host name.
API-20

Validate numeric and string boundaries

TypeBoundaryPriorityHigh
Test data
Zero, negative, a value above the maximum integer, an empty string and a string one character over the limit
Expected result
Each is refused with a field specific message, and a number arriving as a string is handled according to the documented contract rather than coerced silently.
API-21

Preserve unicode and escape sequences through a round trip

TypeNegativePriorityMedium
Test data
Accented characters, emoji, right to left text, quotes, angle brackets and a null byte
Expected result
Stored and returned byte identical, encoded correctly in the response, and the null byte is rejected rather than truncating the value.
API-22

Handle date and time values unambiguously

TypeBoundaryPriorityHigh
Test data
A timestamp with an offset, one without, one at a daylight saving transition and a date only value
Expected result
Timestamps require an explicit offset, date only values are not converted through a timezone, and the value returned equals the value sent.
API-23

Reject an injection attempt in every input path

TypeSecurityPriorityHigh
Test data
Query syntax in a body field, in a query string parameter and in a path segment
Expected result
Treated as literal data everywhere. Path and query parameters are validated with the same rigour as the body, which is where this check is usually missing.
API-24

Behave correctly when a downstream dependency fails

TypeStatePriorityHigh
Test data
Make a required downstream service time out, then return an error
Expected result
Status 502 or 503 with a retryable indication rather than a hung connection, and no partial write is committed when the call fails midway.
API-25

Leave no partial state after a failed multi step write

TypeStatePriorityHigh
Test data
Force a failure between two writes inside the same logical operation
Expected result
Both are rolled back or the operation is safely resumable. A half applied change is worse than a clean failure because nothing reports it.
API-26

Keep an older client working after a schema change

TypeCompatibilityPriorityHigh
Test data
A request from the previous contract version after a new optional field is added
Expected result
Still succeeds. Adding a required field, removing a field or changing a type is breaking and belongs behind a version, not in a patch release.
API-27

Match the response to the published specification

TypeFunctionalPriorityHigh
Test data
Validate every response against the schema, including error responses
Expected result
No undocumented field, no missing documented field and no type mismatch. Error responses are part of the contract and are usually the part that drifts.
API-28

Restrict cross origin access to permitted origins

TypeSecurityPriorityHigh
Test data
A preflight request from a permitted origin, an unknown origin and a null origin
Expected result
Only the permitted origin is reflected, credentials are never allowed alongside a wildcard, and the unknown origin receives no permissive header.

What goes in each field

ID

Required

Stable identifier, prefixed by module.

Test case

Required

What is being verified, in one line.

Type

Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.

Priority

Risk based. Anything that returns the wrong status code, leaks another tenant data, or performs a write twice on retry is High, because every consumer of the endpoint inherits the defect.

Test data

The specific values, including the invalid and boundary ones.

Expected result

Required

The precise observable outcome, including message text where the wording itself is the requirement.

How To Use This

Request another account resource

A passing suite of happy path calls tells you the endpoint works for the person who wrote it. These four conditions are where APIs actually fail.

Authenticate as one tenant, ask for another

Take a valid token and request a resource identifier that belongs to somebody else. This is the most common serious defect in a multi tenant API, and it is one request to check.

Send the fields you should not control

Include identifier, owner, role and balance in a create payload. If any of them are accepted, mass assignment has turned a create endpoint into a privilege escalation.

Retry the write

Send the identical create twice with the same idempotency key. Client libraries retry on timeout automatically, so the retry path is the normal path rather than the rare one.

Page while the data changes

Page through a collection while records are being inserted. Offset pagination shifts under insertion and silently skips records, which no static test will reveal.

What Most Sets Miss

Why API defects reach every consumer

Authorisation is the category that produces real incidents, and it fails at the resource rather than at the route. A route guarded by a valid token is not the same as a resource owned by the caller, and the check that exists on the read path is frequently absent on the write path. The correct response for a resource belonging to someone else is 404 rather than 403, because 403 confirms that the identifier exists and turns a sequential identifier scheme into an enumeration tool. Mass assignment belongs in the same family: a create endpoint that accepts an owner or role field from the client has handed over the permission model.

Status codes carry contractual meaning that implementations routinely blur. A 200 with an empty object for a missing resource forces every consumer to write its own not found detection. Returning 403 where 401 belongs tells the caller nothing about how to recover. Treating PUT as a partial update leaves stale values in fields the client deliberately omitted. None of these throw an error, so they survive testing and then get built into every client that integrates.

Retries and concurrency are the two conditions that a sequential test suite cannot reach. HTTP clients retry automatically on timeout, so a create endpoint without idempotency key support will produce duplicate records in normal operation rather than under abuse. Two concurrent patches to different fields of the same resource should either both survive or be refused with a conflict, and the failure mode to test for is the silent loss of one of them.

Finally, the contract itself drifts, and error responses drift first. Success responses are usually validated against a specification somewhere; error bodies are hand written per branch and end up with inconsistent shapes, missing codes and occasionally a stack trace or query text that should never leave the server. Validating every response including failures against the published schema catches the drift, and it catches the breaking change that was released as a patch because the success path still looked fine.

Suggest an improvement

Testing an API or integration layer?

QAble tests API surfaces end to end, including authorisation per resource, idempotency, concurrency, contract conformance and behaviour when dependencies fail.

API testing services

More test case sets

View all

Test cases for a login page

Test cases
25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.

Test cases for a registration form

Test cases
28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.

Test cases for search functionality

Test cases
28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.

Test cases for a shopping cart

Test cases
27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.

Test cases for checkout and payment

Test cases
30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.

Test cases for file upload

Test cases
28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.

Test cases for forgot password

Test cases
26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.

Test cases for OTP verification

Test cases
26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.

Test cases for user roles and permissions

Test cases
26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.

Test cases for form validation

Test cases
27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.

Test cases for a date picker

Test cases
26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.

Test cases for pagination

Test cases
24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.

Test cases for push notifications

Test cases
26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.

Test cases for reports and data export

Test cases
25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.

Test cases for a chatbot

Test cases
28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.

Test cases for net banking transactions

Test cases
28 cases on duplicate debits from a retried request, concurrent transfers against one balance, daily limits across channels, beneficiary cooling periods, second factor binding and reconciliation.

Test cases for wallet and UPI payments

Test cases
28 cases on payments that time out with no response, idempotency on retry, racing balances, caps across devices, collect request fraud, mandates and refunds.

Test cases for insurance claim submission

Test cases
28 cases on coverage at the date of loss, waiting periods, deductibles and sub limits, exclusions and riders, duplicate claims and settlement reconciliation.

Test cases for patient records in an EHR

Test cases
28 cases on duplicate detection and merge, wrong patient entry, units of measure, allergy and interaction alerting, break glass access and audit of reads.

Test cases for CRM lead management

Test cases
28 cases on duplicate leads under concurrency, routing and the unrouted fallback, round robin races, territory visibility, conversion and bulk import.

Test cases for an ERP purchase order

Test cases
28 cases on approval thresholds, amendments that must reset approval, budget commitment races, over receipt tolerance, three-way match and duplicate invoices.

Test cases for OTT video playback

Test cases
28 cases on bitrate recovery after a dip, DRM renewal mid stream, concurrent stream limits and leaked slots, resume conflicts, ad cue points and offline expiry.

Test cases for game level progression

Test cases
28 cases on save corruption during a crash write, cloud save conflicts, offline queue replay, unlock gating, currency exploits and purchase restore.

Test cases for SSO and social login

Test cases
28 cases on linking an account on an unverified email, state and code replay, redirect allow lists, token signature and issuer, deprovisioning and session rotation.

Test cases for subscription and billing

Test cases
28 cases on mid cycle proration, duplicate and out of order webhooks, renewal double charges, dunning and grace, trials, coupons, metered usage and tax.

Test cases for data tables, filters and sorting

Test cases
28 cases on unstable sorts across pages, filters that must reset pagination, selection surviving a filter change, bulk action scope and export fidelity.

Test cases for session timeout and concurrent login

Test cases
28 cases on tokens that survive sign out, refresh token reuse, idle against absolute lifetime, multi tab expiry, session limits and remote revocation.

Test cases for a multi step form wizard

Test cases
28 cases on values lost to back navigation, refresh and session expiry, step skipping, server side revalidation, duplicate submission and conditional branches.

Test cases for email verification

Test cases
28 cases on token reuse and expiry, invalidating earlier links, account enumeration, header injection, safe address change and mail scanner prefetching.

Test cases for dashboards and analytics widgets

Test cases
28 cases on reconciling against source rows, widgets that disagree, timezone aggregation, zero baselines, no data shown as zero and permission leaks in aggregates.

Test cases for booking and reservation

Test cases
28 cases on concurrent bookings for the last slot, inventory holds that leak, payment without a booking, cancellation boundaries and channel sync.

Test cases for mobile app install and update

Test cases
28 cases on migration chains across skipped versions, crashes during post upgrade migration, forced update lockouts, deep links and clean reinstall.

Test cases for accessibility (WCAG 2.2 AA)

Test cases
28 cases on keyboard only completion, focus management, live region announcements, contrast, reflow at 320 pixels, target size and screen reader verification.

Test cases for performance and load

Test cases
28 cases on spikes with no ramp, recovery after peak, soak and leak detection, pool exhaustion, cold caches, retry storms and data correctness under load.

Test cases for the OWASP Top 10

Test cases
28 cases on broken access control, mass assignment, injection across every input surface, credential stuffing, session invalidation, SSRF and exposed secrets.

Test cases for cross browser compatibility

Test cases
28 cases on storage that throws in private mode, blocked third party cookies, engine date parsing, mobile viewport units, in app browsers and ad blockers.

Test cases for database and data integrity

Test cases
28 cases on uniqueness under concurrency, lost updates, counter races, orphaned rows, migration and backfill safety, replica lag and verified restores.

Test cases for localisation and multi language support

Test cases
28 cases on text expansion, concatenated sentences, plural rules, locale date parsing, decimal separators, right to left layout, collation and encoding.

Want your API contract proven, not assumed?

QAble covers functional, boundary and security paths with ISTQB-certified engineers. Start with a free QA audit of your API.

Talk to QA Advisor