First API trainer MVP

Create User API Practice

Edit a fake Create User API request, inspect realistic responses, then write what you would test and compare your answer with structured API QA checklist coverage.

Start writing test ideas Try API sandbox

How to use this trainer

Choose, send, inspect, write, improve

Safe client-side simulator. No real backend is called and no real data is sent.

1Choose a preset case
2Send a simulated request
3Read the response and QA note
4Write what you would test
5Check your coverage

Interactive sandbox

Try the API request

Edit the request body, choose auth conditions, send a simulated POST /api/users request, and inspect the fake API response.

Request

Build the request

POST/api/users

Request JSONapplication/json

Auth tokenTenantContent-Type

Test case presets

Choose a case, inspect the fake response, then write what you would test.

Happy path

Validation / contract

Auth / permissions

Security / protected fields

Data / consistency

Response

Fake API result

Try valid, validation, auth, permission, duplicate, protected-field, and malformed JSON cases.

Click Send request to see a simulated POST /api/users response.

What to notice

Did the API return the correct status code?
Should this be covered by contract/API tests?
Does failure avoid creating data?

What would you test?

List contract checks, required fields, validation, negative cases, auth, permissions, persistence, side effects, security, error handling, observability, and performance.

Tip: a stronger answer usually mixes happy path, negative cases, state changes, data, backend, UX, accessibility, and risk.

How to structure your answer

Happy pathNegative casesData rulesSecurity/API risksUX/performance

API ReferenceEndpoint, request fields, responses, and business rulesExpand

API reference

Create User endpoint

Use this as supporting reference while you experiment in the sandbox and write test ideas.

Endpoint

POST/api/users

Authentication

Bearer token required

Permission

User must have users:create permission

Success response

201 Created

Request body

{
  "email": "user@example.com",
  "password": "Password123!",
  "name": "John Doe",
  "role": "user"
}

Success response body

{
  "id": "usr_123",
  "email": "user@example.com",
  "name": "John Doe",
  "role": "user",
  "status": "pending_verification",
  "createdAt": "2026-01-01T10:00:00Z"
}

Business rules

email is required
email must be unique
password is required
password must follow password policy
name is required
role defaults to user
only admins can create admin users
status defaults to pending_verification
password must never be returned
created user must be persisted
welcome or verification email may be sent after successful creation
tenant/workspace isolation must be enforced

API interview guide

What this Create User API practice covers

This scenario trains test design for account creation APIs where request validation, defaults, persistence, permissions, and sensitive data handling must work together.

Key risks covered

- Valid create request, required fields, request schema, and 201 Created response.
- Duplicate email, invalid email, weak password, malformed JSON, and wrong content type.
- Protected fields, default role/status, mass assignment, and role escalation prevention.
- Password hashing, password not returned, password not logged, and safe audit records.
- Tenant isolation, database persistence, welcome or verification email failures, retries, and rate limits.

Example interview prompt

How would you test a POST /api/users endpoint that creates a user, validates roles, and returns a pending verification account?

Common mistakes

- Stopping at valid payload and invalid email.
- Missing protected fields such as role, status, tenant, or isAdmin.
- Not checking persistence, audit logs, email side effects, or no-password exposure.