API Testing Hackathon Journey

In today’s software world, most applications no longer live in isolation. Mobile apps, web portals, reporting tools, and third-party platforms all talk to each other through APIs. If APIs fail, everything fails.

That’s why our recent API Testing Hackathon was more than just a technical exercise — it was a real-world simulation of how modern products are validated before reaching customers.

In this blog, I will walk you through how we tested a complete backend system using Swagger, Postman, Gherkin, and Data-Driven Automation, and how we handled real challenges along the way.

We were given a Swagger-based API platform:

The backend consisted of five functional modules:

Module	Purpose
Program Module	Create and manage training programs
Program Batch Module	Assign batches to programs
User Module	Create and manage users
Login Module	Authenticate users and generate tokens
Skill Master Module	Maintain skill data

This is exactly how real SaaS products are built multiple services connected by APIs.

Swagger gave us:

• Endpoint URLs

• Request methods (GET, POST, PUT, DELETE)

• Required headers

• Request bodies

• Response schemas

But Swagger only tells you what should happen, our job was to verify what actually happens by verifying response code.

Setting Up Postman:

Before running any API, we created a Postman Environment.

This is important because real systems don’t hardcode values — they use:

• Base URLs

• Tokens

• User IDs

• Program IDs

We created environment variables such as:

• base_url

• auth_token

• user_id

• program_id

• batch_id

This allowed us to:

• Run the same tests across environments

• Chain APIs together

• Avoid manual copy-paste

Then we added mandatory headers, including:

• Authorization: Bearer {{auth_token}}

• Content-Type: application/json

This is exactly how production systems work.

Login First — Because Nothing Works Without Auth

The Login Module was our starting point.

We called:

POST /login

This returned a JWT token.

We wrote a Postman Pre-Script to extract the token:

pm.environment.set("auth_token", pm.response.json().token);

Now every request automatically used the latest valid token — no manual work.

This is a real-world API automation pattern used in companies.

Validating API Responses

For every API, we checked:

What we validated	Why it matters
Status Code	200, 201, 400, 401, 409
Response Body	Data correctness
Error Messages	Business rule validation
Headers	Security & format

Example:

For Create User:

POST /users

We validated:

• 201 when user created

• 409 when duplicate email used

• 400 when mandatory field missing

• 401 when token is invalid

We wrote Postman Tests:

pm.test("Status is 201", function () {

pm.response.to.have.status (201);

});

This turned Postman into a real test automation tool.

Data-Driven Testing — One Test, Many Inputs

Instead of testing one user, we tested hundreds of users.

We created a CSV file: name, email ,role

Padmaja,padmaja@test.com,Admin

John,john@test.com,User

...

Postman’s Collection Runner executed the same API with multiple data rows.

This helped us validate:

• Duplicate handling

• Email uniqueness

• Role mapping

• Validation rules

This is how enterprise QA teams test scalability.

Writing Gherkin Scenarios

We didn’t just test APIs — we wrote business scenarios.

Example:

Scenario: Create a new program

Given the user is authenticated

When the user sends a POST request to create a program

Then the API should return status 201

And the program should be saved in the system

This bridges:

• QA

• Developers

• Product Owners

Everyone understands what is being tested.

Real Challenges We Faced

This hackathon was not smooth — just like real projects.

Challenge 1: Token Expiry

Some tests failed randomly because tokens expired.

Solution: We automated login and token refresh in pre-scripts.

Challenge 2: Data Dependency

Program Batch APIs failed when program IDs were missing.

Solution: We created chaining:

• Create Program → Store ID

• Create Batch → Use Program ID

Challenge 3: Inconsistent Error Messages

Some APIs returned:

• 400 with wrong messages

• 500 instead of validation errors

Solution: We documented defects and raised API contract issues in tracking bug tool called JIRA.

Why This Hackathon Was More Than Testing

This hackathon taught us:

• How backend systems really work

• How business rules are enforced

• How data flows across modules

As someone moving toward Technical Product Manager / Product Owner roles, this is powerful because:

If you understand APIs, you understand the product.

                  The final output :

                  Automated API collections

• Environment-driven execution

• Gherkin scenarios

• Data-driven test coverage

• Bug reports based on real failures

This is exactly how companies test their products.

Conclusion:

This hackathon showed that API testing is not just QA, it is product validation.

We didn’t just click buttons we validated business logic, data integrity, security, and scalability.

And that’s what makes this experience valuable for both QA Engineers and Product Leaders.