API Fundamentals · Interactive trainer

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

Endpoint

POST/api/users

Create account contract

Auth

Bearer token

Requires users:create permission

Success

201 Created

Persisted user response

Rules

Validation + isolation

Unique email, password policy, tenant checks

Interactive workspace

Send a request, inspect the response, then write test ideas without leaving the workspace.

Write test ideas

How to use this trainer

One focused API testing workflow

Pick a preset or edit the JSON, inspect the simulated response, then turn what you learned into test coverage.

1Try request
2Inspect response
3Write test ideas

Interactive sandbox

Try the request, inspect the response

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

JSON bodyapplication/json

Auth tokenTenantContent-Type

Test case presets

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

Happy path

2 cases

Validation / contract

7 cases

Auth / permissions

4 cases

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?

Test ideas

What would you test?

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

Ready to evaluate: include happy path, negative cases, auth, data, errors, and observability.

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.