Back to API Practice

Security/Auth path · Step 2

Password Reset API Practice

Send fake password reset requests, inspect realistic token and validation responses, then write what you would test and compare your answer with structured API QA checklist coverage.

Start writing test ideasTry API sandbox

Endpoints

request + confirm

Two-step reset flow

Auth

Public reset

No bearer token required

Success

200 / 202

Generic safe response

Rules

Token safety

Expiry, reuse, rate limits, session invalidation

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.

  1. 1Try request
  2. 2Inspect response
  3. 3Write test ideas

Interactive sandbox

Try the request, inspect the response

Switch between reset-request and reset-confirm flows, edit JSON, send a simulated request, and inspect the fake API response. No real data is sent.

Request

Build the reset request

POST/api/auth/password-reset/request

Test case presets

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

Reset request flow

7 cases

Confirm reset flow

8 cases

Contract / error handling

3 cases

Response

Fake API result

Send a simulated request to see status, JSON response, QA note, and the risks this case should add to your answer.

Test ideas

List reset request checks, token expiry and reuse, password policy, user enumeration prevention, rate limiting, session invalidation, email side effects, safe errors, audit logs, metrics, 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

Password reset endpoints

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

Request endpoint

POST/api/auth/password-reset/request

Confirm endpoint

POST/api/auth/password-reset/confirm

Authentication

No bearer token required for the public reset flow

Safe request response

200 or 202 with a generic body

Reset request body

{
  "email": "qa.user@example.com"
}

Reset request success body

{
  "message": "If the account exists, password reset instructions will be sent."
}

Reset confirm body

{
  "token": "valid-reset-token",
  "newPassword": "NewPassword123!"
}

Reset confirm success body

{
  "message": "Password has been reset successfully."
}

Business rules

  • existing and unknown email requests return the agreed generic safe response
  • reset emails are sent or queued only for eligible accounts
  • reset tokens are hard to guess, time-limited, and single-use
  • expired, invalid, and reused tokens are rejected safely
  • new passwords must satisfy password policy
  • passwords and reset tokens are never returned, logged, or exposed
  • sessions, refresh tokens, or remember-me sessions are invalidated when required
  • request volume is rate limited to prevent abuse and mailbox flooding
  • email provider, database, and auth service failures are handled safely
  • reset request and confirm events are logged and measured without secrets

API interview guide

What this Password Reset API practice covers

This scenario trains recovery-flow testing where reset requests, token lifecycle, password change rules, sessions, and email delivery create security and reliability risk.

Key risks covered

  • - Request reset email for existing and unknown users without leaking account existence.
  • - Valid, expired, reused, malformed, and older reset tokens.
  • - Weak password, mismatch, same-as-old password, and password policy validation.
  • - Old password rejection, new password success, and session invalidation after reset.
  • - Rate limiting, email provider failure, safe token logging, wrong content type, and backend outages.

Example interview prompt

How would you test password reset request and confirm APIs with email links, one-time tokens, and session invalidation?

Common mistakes

  • - Only testing an existing email and a successful reset.
  • - Forgetting old links, token reuse, unknown email privacy, and rate limits.
  • - Not checking email delays, session invalidation, or token leakage in logs.
Related practice:Login APIToken Refresh APIMFA Challenge API