Interactive API trainer

Login API Testing Practice

Edit a fake Login API request, inspect realistic auth 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/auth/login request, and inspect the fake API response. No real data is sent.

Request

Build the login request

POST/api/auth/login

Request JSONapplication/json

Content-Type

Test case presets

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

Happy path

Validation / contract

Credential / account states

Security / abuse

Response

Fake API result

Send a simulated request to see the HTTP status, JSON response, QA note, and the risks this case should make you mention in your answer.

What would you test?

List contract checks, valid email/username login, missing fields, wrong password, unknown users, account states, MFA, token/session behavior, security, rate limiting, observability, and reliability.

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

Login endpoint

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

Endpoint

POST/api/auth/login

Authentication

No bearer token required

Identifiers

Email/password or username/password if username login is supported

Success response

200 OK

Request body

{
  "email": "qa.user@example.com",
  "password": "Password123!",
  "rememberMe": false
}

Success response body

{
  "accessToken": "eyJhbGciOi...",
  "refreshToken": "rt_fake_refresh_token",
  "tokenType": "Bearer",
  "expiresIn": 900,
  "user": {
    "id": "usr_123",
    "email": "qa.user@example.com",
    "role": "user",
    "status": "active"
  }
}

Business rules

email or username is required
password is required
invalid credentials return a generic safe error
unknown users return the same error as wrong password
locked, disabled, and unverified users follow product policy
MFA-enabled users receive a challenge before full tokens
rate limiting protects repeated attempts
rememberMe changes session lifetime only according to requirements
passwords and tokens are never logged or exposed
successful and failed authentication events are logged safely

API interview guide

What this Login API practice covers

This scenario trains API test design for authentication endpoints where credential validation, account states, token creation, and safe error handling all matter.

Key risks covered

- Valid email or username login with the expected token response.
- Missing identifiers, missing passwords, malformed emails, wrong passwords, and unknown users.
- Locked, disabled, unverified, deleted, and MFA-required account states.
- Generic errors that prevent user enumeration and brute-force clues.
- Rate limiting, secure token/session behavior, password exposure checks, and auth telemetry.

Example interview prompt

How would you test a Login API that accepts email or username plus password and returns access and refresh tokens?

Common mistakes

- Only testing valid login and wrong password.
- Forgetting locked, disabled, unverified, and MFA-enabled users.
- Not checking token response schema, safe errors, logging, or rate limiting.