The most useful API testing prompts give the model the endpoint contract (ideally an OpenAPI document), the auth method and your test tool, then ask for specific cases: invalid input, wrong credentials, another user's data and repeated requests, not just the happy path. Below are 13 API testing prompts for ChatGPT, Claude, Claude Code and Codex for planning tests, writing them in Playwright or Postman, testing auth and checking behavior under real conditions.
How to use these prompts
Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{tool:Playwright}} means Playwright unless you change it.
Three habits give much better tests:
- Give the contract. An OpenAPI document tells the model every endpoint, parameter and response shape. Without it, paste the route handler and an example request and response.
- Ask for the unhappy paths by name. Models write success cases first and often stop there.
- Run every test and watch it fail once. Break the code or the expected value on purpose. A test that can't fail proves nothing.
In an agent, point it at the route files and the OpenAPI file and let it run the suite against a local server.
This page covers testing an HTTP API from the outside. For unit tests and testing a single endpoint against a real database, see the unit test prompts. For designing the API itself, see the API design prompts.
How do you plan API tests with AI?
1. Turn an OpenAPI document into a test plan
A plan first means you can review coverage before any code exists.
Here is our OpenAPI document. Write a test plan for {{scope:the /orders endpoints}}.
For each operation, list test cases under these headings: success, input
validation, authentication, authorization (other users' data), not found,
conflicts and state rules, and response schema. For each case give the
request, the expected status code and what to assert in the body.
Mark cases the document doesn't define clearly as "Spec gap:".
{{openapi}}
2. List negative and boundary cases for one endpoint
Most API bugs live in input the developer never imagined.
List negative and boundary test cases for this endpoint:
{{endpoint_definition}}
Cover: missing required fields, wrong types, empty strings and arrays,
values at and just past each limit, very long strings, unicode and
emoji, unexpected extra fields, malformed JSON, wrong Content-Type, and
duplicate query parameters. Give a table: case, request body or
parameters, expected status, and expected error message or code.
3. Turn a curl command into a test
Useful when you've just debugged a request by hand and want to keep it.
Turn this curl command and its response into an automated test in
{{tool:Playwright}}.
{{curl_command}}
Response:
{{response}}
Read secrets and the base URL from environment variables, never from the
test file. Assert the status, the important fields and their types, not
values that change every run (IDs, timestamps). Add one negative case
next to it.
How do you write API tests in code?
4. Write Playwright API tests
Playwright's request fixture sends HTTP requests without loading a page and respects baseURL and extraHTTPHeaders set in playwright.config. toBeOK() asserts a status in the 200 to 299 range.
Write Playwright API tests in TypeScript for {{resource:the /projects endpoints}}.
Endpoints and expected behavior:
{{endpoints}}
Requirements:
- Use the request fixture; put baseURL and auth headers in
playwright.config under use, reading the token from an environment
variable.
- Create test data in beforeAll and remove it in afterAll so tests don't
depend on existing records.
- One behavior per test, with a name that says what it checks.
- Assert status and body shape for success and error cases.
5. Write Postman test scripts
Postman runs post-response scripts after each response, using pm.test and Chai-style assertions. Scripts can sit on a request, folder or collection.
Write Postman post-response test scripts for this request:
{{request}}
Example response:
{{response}}
Use pm.test with clear names. Check the status code, the response time
against {{max_ms:500}} ms, required fields and their types, and that error
responses use our error format. Save {{save_field:the new resource ID}} to
a collection variable for the next request. Tell me which checks belong
at the collection level so every request runs them.
6. Check responses against the schema
Documentation and implementation drift apart quietly. Schema checks in tests catch it on the next run.
Add schema validation to our API tests so every response is checked
against our OpenAPI document.
Test tool: {{tool:Vitest}}
Validator: {{validator:the JSON Schema validator we already use}}
OpenAPI file: {{openapi_path:openapi.yaml}}
Write a helper that looks up the schema for an operation and status code
and fails with a readable message showing which field broke the contract.
Include error responses, not only success. Show how to use it in two
existing tests:
{{example_tests}}
7. Write consumer-driven contract tests
When two services or teams depend on each other, contract tests catch breaking changes without a full end-to-end environment. In Pact, the contract is generated from the consumer's tests.
Our {{consumer:web frontend}} calls {{provider:the billing API}}. Help me
write consumer-driven contract tests with {{tool:Pact}}.
Calls the consumer makes:
{{calls}}
Write the consumer tests that define these interactions, using matchers
for values that vary (IDs, dates) instead of exact values. Then explain
how the provider verifies the contract in its CI, what provider states it
needs to set up, and how a breaking change shows up.
How do you test API authentication and authorization?
8. Test access to other users' data
Broken Object Level Authorization is first on the OWASP API Security Top 10 2023. The test is simple: user B asks for user A's object.
Write authorization tests for these endpoints:
{{endpoints}}
Set up two users in different {{tenant:accounts}}, each with their own
records. For every endpoint that takes an object ID (path, query or
body), test that user B cannot read, update or delete user A's object,
including nested IDs. Also test that a normal user cannot call admin-only
endpoints. State what status code each case should return and make the
choice consistent.
9. Test authentication failures
Login flows tend to get tested with a valid token and nothing else.
Write tests for authentication failures on {{api:our REST API}}, which uses
{{auth:bearer JWTs}}.
Cases: no credentials, malformed header, expired token, token signed with
the wrong key, token for a deleted or disabled user, and a token with too
few scopes. Check that missing or bad credentials return 401 and that a
valid user without permission gets 403. Per RFC 9110, a 401 response must
include a WWW-Authenticate header, so assert it. Make sure no error
response leaks stack traces or internal details.
The 401 rule comes from RFC 9110, section 15.5.2, the HTTP semantics standard.
How do you test API behavior under real conditions?
10. Test idempotency and retries
Clients retry on timeouts, so the same request will arrive twice. RFC 9110 defines PUT, DELETE and the safe methods as idempotent; POST is not, unless you add something like an idempotency key.
Write tests that check {{api:our orders API}} handles repeated requests
safely.
- Sending the same PUT or DELETE twice leaves the same final state.
- POST {{create_endpoint:/orders}} with the same {{key_header:Idempotency-Key}}
header twice creates one order and returns the same response.
- The same key with a different body is rejected.
- Two identical requests sent at the same moment don't both succeed.
Explain what each test proves and what bug it would catch.
11. Test pagination and sorting
Pagination bugs show up as missing or duplicate items, usually only in production data.
Write tests for pagination on {{endpoint:GET /orders}}, which uses
{{style:cursor-based pagination}}.
Create {{count:25}} records with some identical sort values. Then check:
walking every page returns each record exactly once; the last page signals
the end correctly; page size limits are enforced; invalid cursors or
offsets return a clear error; sort order is stable when values tie; and
records created between page requests don't cause duplicates or gaps.
12. Test rate limits and error formats
Clients need predictable errors. These tests make your error contract real.
Write tests for error handling and rate limiting on {{api:our API}}.
Error format: {{error_format:RFC 9457 problem details}}
Rate limit: {{limit:100 requests per minute per API key}}
Check that every error status (400, 401, 403, 404, 409, 422, 429, 500)
uses the same error format with the documented fields. For rate limits,
check that requests over the limit get 429, that any headers we document
(such as Retry-After) are present and correct, and that the limit resets.
Keep the rate limit test fast by using a test-only low limit if possible.
13. Make API tests independent and repeatable
Tests that pass alone and fail together usually share data. This prompt redesigns setup and cleanup.
Our API tests are flaky when run in parallel or in a different order.
Test setup and a few example tests:
{{tests}}
Find shared state: records created by one test and used by another,
fixed IDs or emails that collide, tests that depend on order, and
assertions on counts of all records. Rewrite the setup so each test
creates its own uniquely named data and cleans it up, and suggest how to
reset the test environment between runs.
What should a good API test suite cover?
| Area | What to check | Prompts |
|---|---|---|
| Success paths | Status, body shape, headers | 3, 4, 5 |
| Bad input | Validation errors with clear messages | 2 |
| Contract | Responses match the OpenAPI document; consumers still work | 1, 6, 7 |
| Authentication | 401 for missing or bad credentials | 9 |
| Authorization | No access to other users' objects or admin functions | 8 |
| Retries | Repeated requests don't duplicate work | 10 |
| Lists | Pagination returns every item once | 11 |
| Errors and limits | One error format, 429 when over the limit | 12 |
| Reliability | Tests run in any order, in parallel | 13 |
For a broader security pass on the same API, see the security review prompts. If you run end-to-end tests in Playwright too, the Playwright best practices skill guide covers a skill for writing them.
Turn your favorite one into a skill
If your team writes API tests every week, the test plan and authorization prompts make good skills, so Claude Code or Codex applies the same checklist to every new endpoint. Paste one into the free SKILL.md generator to get a valid SKILL.md. To run the suite on every pull request, the CI/CD prompts cover writing the pipeline.
Kipt keeps prompts like these as Markdown in a private GitHub repo you own. Blanks like {{tool:Playwright}} stay fillable, Cmd+K finds any prompt, and skills you save there install into Claude Code or Codex with one command.