Security/Auth path · Step 1

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

Endpoint

POST/api/auth/login

Primary auth request

Auth

Public endpoint

No bearer token required

Success

200 OK

Token body or MFA challenge

Rules

Safe auth behavior

Generic errors, rate limits, account states

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

Request

Build the login request

POST/api/auth/login

JSON bodyapplication/json

Content-Type

Test case presets

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

Happy path

2 cases

Validation / contract

6 cases

Credential / account states

5 cases

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.

Test ideas

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.

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

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.