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.

POST/api/auth/password-reset/{request,confirm}
Auth Public / reset tokenSuccess 200 OK / 202 Accepted
Rules
  • Token expiry, reuse, rate limits, and session invalidation

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.

1. EDIT 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

2. INSPECT 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.

3. WRITE TEST IDEAS

Test Ideas Notebook

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.

Use Markdown lists to organize your test ideas.

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

Resources / Test Checklist

Rules
  • Token expiry, reuse, rate limits, and session invalidation
Endpoints
  • POST /api/auth/password-reset/{request,confirm}
Headers
  • Review request headers in the API Reference.
Scenarios
  • Happy path
  • Negative cases
  • Data rules
  • Security/API risks
  • UX/performance

4. COMPARE ANSWER

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

Reset request body

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

Reset confirm body

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

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 success body

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

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