API Testing Practice

Register User API

There's no UI here - this is a real REST endpoint to test with Postman, curl, or your HTTP client of choice. Practice validating methods, headers, payloads, and business logic against a live API.

This endpoint has no browser interface. Use Postman, Insomnia, curl, or your automation framework to send requests to it.

Endpoint

POSThttps://practise.assertqa.com/api/register

Only POST is implemented for registration. Any other method (GET, PUT, DELETE, PATCH) returns 405 Method Not Allowed. OPTIONS is available for CORS preflight requests.

Headers

Content-Typeapplication/json

Request Body

namestringrequired
  • Must be a non-empty string
emailstringrequired
  • Must be a valid email address (e.g. user@example.com)
passwordstringrequired
  • At least 8 characters long
  • At least one uppercase letter
  • At least one lowercase letter
  • At least one number
  • At least one special character
{
  "name": "Test Cat",
  "email": "test.cat@example.com",
  "password": "TestCat123!"
}

Possible Responses

201 CreatedSuccess

All fields are valid. The registration request is accepted (no account is actually persisted - this is a practice sandbox).

{
  "success": true,
  "message": "User registration request accepted",
  "data": {
    "name": "Test Cat",
    "email": "test.cat@example.com"
  }
}
422 Unprocessable EntityValidation Failed

One or more fields failed validation. The details array lists every rule that failed, not just the first one.

{
  "success": false,
  "error": "Validation failed",
  "details": [
    "email must be a valid email address",
    "password must be at least 8 characters long"
  ]
}
400 Bad RequestMalformed Payload

The request body isn't valid JSON at all (e.g. a trailing comma or unclosed brace).

{
  "success": false,
  "error": "Invalid request payload",
  "details": ["Invalid JSON body"]
}
405 Method Not AllowedWrong HTTP Method

Sent with any method other than POST or OPTIONS.

{
  "success": false,
  "error": "Method not allowed"
}

Scenarios to Test

Use these as a starting checklist, then come up with your own. A good API tester tries to break things the developer didn't think of.

HTTP Methods

  • Send a valid POST request and confirm you get 201 Created.
  • Try GET, PUT, DELETE, and PATCH on the same URL - confirm each returns 405 Method Not Allowed.
  • Send an OPTIONS request and check the CORS headers in the response (Access-Control-Allow-Methods, Access-Control-Allow-Origin).

Headers

  • Send a valid payload with Content-Type: application/json - this is the documented contract.
  • Send the same payload with no Content-Type header at all. Does the response change?
  • Send the same payload with Content-Type: text/plain. Should an API accept that? Does this one?
  • Try an unsupported Accept header and see if anything in the response changes.

Payload Content

  • Omit name, email, and password one at a time - check the error message and details array for each.
  • Send an empty JSON body {} and confirm all three fields are reported as required.
  • Send malformed JSON (e.g. a trailing comma) - confirm you get 400 Bad Request, not 422.
  • Add an unexpected extra field, e.g. "role": "admin" - does the API strip it or echo it back in the response? What would that mean for a real production API?

Payload Quality

  • Test email edge cases: missing @, missing domain, spaces, uppercase domains, plus-addressing (user+test@example.com).
  • Send a field with the wrong type, e.g. password as a number instead of a string.
  • Test boundary lengths - a 1-character name vs. a name thousands of characters long.
  • Try special characters and injection-style strings in name and email (<script>, SQL fragments, emoji) and see how the API handles them.

Business Logic

  • Password length boundary: test exactly 7 and exactly 8 characters.
  • Remove one password rule at a time (no uppercase, no lowercase, no number, no special character) and confirm the details array names that specific rule.
  • Register the same email twice in a row. Does the API reject the duplicate or accept both? Is that the behavior you'd expect from a real registration endpoint?

Need expert QA help? We offer team training, automation consulting, and end-to-end QA services.

Talk to us

Need this tested professionally?

Building or testing real API integrations? AssertQA delivers test automation services, manual testing services, and API testing services for teams that need real-world quality.

Talk to our QA team