Browse the Knowledge Hub56 resources
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat 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
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
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.
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 improvementTesting 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 servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 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 cases26 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 cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 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 cases26 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 cases24 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 cases26 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 cases25 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 cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Test cases for net banking transactions
Test cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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 cases28 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.