Automation Exercise
API Reference
Printable documentation modeled after a Swagger / OpenAPI reference page
Base URL [Link]
Document status Unofficial inferred reference for test design
and QA onboarding
Generated 20 Mar 2026
Machine-readable companion OpenAPI YAML / JSON can be delivered
alongside this document
Scope and confidence
This document is inferred from the public Automation Exercise API list, observed live responses
for catalog endpoints, and a public Postman collection that shows request bodies and
assertions.
Treat it as a practical QA reference, not as an authoritative backend contract.
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
1. Quick start
Automation Exercise exposes a small set of practice APIs for product catalog, search, login
verification, and basic account management. The public site documents 14 testing scenarios,
but several scenarios reuse the same path and method with different payload conditions.
Important transport behavior
The official API list advertises business response codes such as 201, 400, 404, and 405.
A public Postman collection repeatedly asserts HTTP 200 for several of those scenarios while
checking the business outcome in JSON field responseCode.
For robust testing, validate both: HTTP status and JSON [Link]/message.
2. Official scenario map
Scenario Method Path Intent
API 1 GET /api/productsList Get all products list
API 2 POST /api/productsList Unsupported method
API 3 GET /api/brandsList Get all brands list
API 4 PUT /api/brandsList Unsupported method
API 5 POST /api/searchProduct Search product
Missing search_product
API 6 POST /api/searchProduct
parameter
API 7 POST /api/verifyLogin Valid credentials
Missing email or
API 8 POST /api/verifyLogin
password
API 9 DELETE /api/verifyLogin Unsupported method
API 10 POST /api/verifyLogin Invalid credentials
API 11 POST /api/createAccount Create/register user
API 12 DELETE /api/deleteAccount Delete user account
API 13 PUT /api/updateAccount Update user account
/api/
API 14 GET Get user detail by email
getUserDetailByEmail
3. Shared conventions
Server base URL: [Link]
Authentication: no bearer token or API key is documented on the public API list.
Most mutating endpoints are exercised publicly as multipart/form-data rather than raw JSON.
Response envelope convention: many operations return responseCode and message; catalog
operations return responseCode with a data array.
For destructive tests, generate disposable users and clean them up with deleteAccount.
4. Detailed operation reference
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
Get All Products List
GET /api/productsList
Covers official scenarios: API 1
Returns the full product catalog.
Property Value
Full URL [Link]
Method GET
Content type Request body: none · Response: application/json
Parameters
None.
Request body
No documented request body fields.
Sample request
curl --request GET \
'[Link]
Sample success response
{
"responseCode": 200,
"products": [
{
"id": 1,
"name": "Blue Top",
"price": "Rs. 500",
"brand": "Polo",
"category": {
"usertype": {"usertype": "Women"},
"category": "Tops"
}
}
]
}
Testing notes
Official API list says response code 200 and all products list.
Live endpoint response exposes Product fields: id, name, price, brand, category, and
[Link].
Unsupported Method on Products List
POST /api/productsList
Covers official scenarios: API 2
POST is not supported for this resource.
Property Value
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
Full URL [Link]
Method POST
Request body: none required · Response:
Content type
application/json
Parameters
None.
Request body
No documented request body fields.
Sample request
curl --request POST '[Link] \
--form ''
Sample success response
{
"responseCode": 405,
"message": "This request method is not supported."
}
Testing notes
The official page describes this as response code 405.
A public Postman collection asserts HTTP 200 while the JSON body contains responseCode 405,
so both transport-level and body-level outcomes should be checked during testing.
Get All Brands List
GET /api/brandsList
Covers official scenarios: API 3
Returns the available brand list.
Property Value
Full URL [Link]
Method GET
Content type Request body: none · Response: application/json
Parameters
None.
Request body
No documented request body fields.
Sample request
curl --request GET \
'[Link]
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
Sample success response
{
"responseCode": 200,
"brands": [
{"id": 1, "brand": "Polo"},
{"id": 2, "brand": "H&M"}
]
}
Testing notes
The live response currently contains repeated brand names with different ids; do not assume
brand values are unique.
Unsupported Method on Brands List
PUT /api/brandsList
Covers official scenarios: API 4
PUT is not supported for this resource.
Property Value
Full URL [Link]
Method PUT
Request body: optional/ignored · Response:
Content type
application/json
Parameters
None.
Request body
No documented request body fields.
Sample request
curl --request PUT '[Link] \
--form ''
Sample success response
{
"responseCode": 405,
"message": "This request method is not supported."
}
Testing notes
The official page documents response code 405 and the same unsupported-method message
used elsewhere.
POST Search Product
/api/searchProduct
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
Covers official scenarios: APIs 5-6
Searches products by keyword passed as form-data.
Property Value
Full URL [Link]
Method POST
Request body: multipart/form-data · Response:
Content type
application/json
Parameters
None.
Request body
Field Type Required Description
Keyword such as top,
search_product string Yes
tshirt, or jean.
Sample request
curl --request POST '[Link] \
--form 'search_product=top'
Sample success response
{
"responseCode": 200,
"products": [
{
"id": 1,
"name": "Blue Top",
"price": "Rs. 500",
"brand": "Polo",
"category": {
"usertype": {"usertype": "Women"},
"category": "Tops"
}
}
]
}
Known negative / alternate outcomes
responseCode message When to expect it
Bad request, search_product
400 parameter is missing in POST Official negative scenario API 6.
request.
Testing notes
The public Postman collection sends this request as form-data, not raw JSON.
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
Verify Login
POST /api/verifyLogin
Covers official scenarios: APIs 7-10
Checks whether submitted credentials correspond to an existing user.
Property Value
Full URL [Link]
Method POST
Request body: multipart/form-data · Response:
Content type
application/json
Parameters
None.
Request body
Field Type Required Description
email string Yes User email address.
password string Yes Password for the user.
Sample request
curl --request POST '[Link] \
--form 'email=user@[Link]' \
--form 'password=secret123'
Sample success response
{
"responseCode": 200,
"message": "User exists!"
}
Known negative / alternate outcomes
responseCode message When to expect it
Bad request, email or password
400 parameter is missing in POST Official negative scenario API 8.
request.
Official negative scenario API 10 for
404 User not found!
invalid credentials.
Testing notes
The official page models this as response-message driven, without a token or session contract.
The public Postman collection uses multipart form-data and validates body messages for
success and negative cases.
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
Unsupported Method on Verify Login
DELETE /api/verifyLogin
Covers official scenarios: API 9
DELETE is not supported on the login verification endpoint.
Property Value
Full URL [Link]
Method DELETE
Content type Request body: ignored · Response: application/json
Parameters
None.
Request body
No documented request body fields.
Sample request
curl --request DELETE '[Link] \
--form ''
Sample success response
{
"responseCode": 405,
"message": "This request method is not supported."
}
Testing notes
The public Postman collection again checks HTTP 200 plus [Link] 405, so body-
level assertions matter.
Create / Register User Account
POST /api/createAccount
Covers official scenarios: API 11
Creates a new user account from a multipart form-data payload.
Property Value
Full URL [Link]
Method POST
Request body: multipart/form-data · Response:
Content type
application/json
Parameters
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
None.
Request body
Uses schema: AccountUpsertRequest (see section 5.1).
Sample request
curl --request POST '[Link] \
--form 'name=Robert1234567890' \
--form 'email=email1234567890@[Link]' \
--form 'password=pass1234567890' \
--form 'title=Mr' \
--form 'birth_date=1' \
--form 'birth_month=1' \
--form 'birth_year=1996' \
--form 'firstname=Robert' \
--form 'lastname=Rozwadowski' \
--form 'company=Pierogi' \
--form 'address1=1134 Columbia Road' \
--form 'address2=Most' \
--form 'country=United States' \
--form 'zipcode=98607' \
--form 'state=Texas' \
--form 'city=Dallas' \
--form 'mobile_number=111222333'
Sample success response
{
"responseCode": 201,
"message": "User created!"
}
Testing notes
The official page says response code 201.
A public Postman collection checks HTTP 200 and JSON body responseCode 201 for this
scenario.
Delete User Account
DELETE /api/deleteAccount
Covers official scenarios: API 12
Deletes an account identified by email and password.
Property Value
Full URL [Link]
Method DELETE
Request body: multipart/form-data · Response:
Content type
application/json
Parameters
None.
Request body
Field Type Required Description
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
email string Yes Account email.
password string Yes Account password.
Sample request
curl --request DELETE '[Link] \
--form 'email=user@[Link]' \
--form 'password=secret123'
Sample success response
{
"responseCode": 200,
"message": "Account deleted!"
}
Testing notes
Destructive operation: use disposable test data or create-then-delete flow when automating.
Update User Account
PUT /api/updateAccount
Covers official scenarios: API 13
Updates an existing user account using the same field set as account creation.
Property Value
Full URL [Link]
Method PUT
Request body: multipart/form-data · Response:
Content type
application/json
Parameters
None.
Request body
Uses schema: AccountUpsertRequest (see section 5.1).
Sample request
curl --request PUT '[Link] \
--form 'name=Robert1234567890' \
--form 'email=user@[Link]' \
--form 'password=secret123' \
--form 'title=Mr' \
--form 'birth_date=1' \
--form 'birth_month=1' \
--form 'birth_year=1996' \
--form 'firstname=Robert' \
--form 'lastname=Rozwadowski' \
--form 'company=Pierogi' \
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
--form 'address1=1134 Columbia Road' \
--form 'address2=Most' \
--form 'country=United States' \
--form 'zipcode=98607' \
--form 'state=Texas' \
--form 'city=Dallas' \
--form 'mobile_number=111222333'
Sample success response
{
"responseCode": 200,
"message": "User updated!"
}
Testing notes
The public Postman collection reuses the same multipart field set as createAccount and
validates [Link] = User updated!.
Get User Detail By Email
GET /api/getUserDetailByEmail
Covers official scenarios: API 14
Fetches the user detail object for a supplied email.
Property Value
[Link]
Full URL
getUserDetailByEmail
Method GET
Content type Request body: none · Response: application/json
Parameters
Name In Type Required Description
Email address to
email query string Yes
look up.
Request body
No documented request body fields.
Sample request
curl --request GET \
'[Link]
Sample success response
{
"responseCode": 200,
"user": {
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
"id": 123,
"name": "Robert1234567890",
"email": "user@[Link]",
"title": "Mr",
"birth_day": "1",
"birth_month": "1",
"birth_year": "1996",
"first_name": "Robert",
"last_name": "Rozwadowski",
"company": "Pierogi",
"address1": "1134 Columbia Road",
"address2": "Most",
"country": "United States",
"state": "Texas",
"city": "Dallas",
"zipcode": "98607"
}
}
Testing notes
The official page only states “User Detail”; the field list above is inferred from public Postman
assertions and request examples, not from an official response schema.
5. Shared schemas and model notes
5.1 AccountUpsertRequest
Field Type Required Description
Display name used during
name string Yes
registration/update.
Email address. Used as
email string Yes
account identifier.
password string Yes Account password.
Examples shown publicly:
title string Yes
Mr, Mrs, Miss.
birth_date string Yes Birth day value.
birth_month string Yes Birth month value.
birth_year string Yes Birth year value.
First name field used by
firstname string Yes
create/update endpoints.
Last name field used by
lastname string Yes
create/update endpoints.
company string No Company name.
address1 string Yes Primary address line.
address2 string No Secondary address line.
country string Yes Country name.
zipcode string Yes Postal/zip code.
state string Yes State/region.
city string Yes City.
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
mobile_number string Yes Phone number.
5.2 Common response models
Model Shape Notes
Used for method-not-supported,
responseCode: integer; message:
GenericAppResponse login verification, create, update,
string
and delete flows.
category contains category and
Product id, name, price, brand, category
nested [Link].
Brand id, brand Observed live from /api/brandsList.
id, name, email, title, birth_day,
birth_month, birth_year, first_name,
Field set is inferred from public
UserDetail last_name, company, address1,
Postman assertions and examples.
address2, country, state, city,
zipcode
5.3 Minimal schema examples
{
"GenericAppResponse": {
"responseCode": 200,
"message": "User exists!"
},
"Brand": {
"id": 1,
"brand": "Polo"
},
"Product": {
"id": 1,
"name": "Blue Top",
"price": "Rs. 500",
"brand": "Polo",
"category": {
"usertype": {"usertype": "Women"},
"category": "Tops"
}
}
}
6. QA guidance for automation
Prefer data-driven tests: create a disposable user first, then reuse that identity for verifyLogin,
getUserDetailByEmail, updateAccount, and deleteAccount.
For endpoints documented as unsupported methods, assert both the transport status and the
JSON message body.
Do not hard-code uniqueness assumptions for brand names or product ids beyond what the API
actually returns.
Because the public site is a practice target, keep tests resilient to minor catalog data drift while
still validating response shape.
If you later capture HAR, Postman, or real backend traffic, update this inferred reference into
an authoritative contract.
7. Source basis used for this printable reference
Official public API list published by Automation Exercise.
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)
Observed live JSON for /api/productsList and /api/brandsList.
Public Postman collection that documents request form-data and asserts response body
behavior across all published scenarios.
Automation Exercise API Reference — Swagger-style printable document (unofficial inferred spec)