TIDAL Postman Tests

Postman API test automation project for validating TIDAL API endpoints, authentication, and data integrity.

Project Summary

This project is a QA portfolio piece built around the TIDAL API v2. It demonstrates API test automation skills using Postman, Postman CLI, Newman, and GitHub Actions through smoke, functional, integration, negative, and data-driven testing. The project also highlights documentation, debugging, CI reliability, and portfolio presentation, making it both a practical automation example and a reflection of my background in music and quality engineering.

Why I Chose TIDAL

I chose the TIDAL API for this portfolio project because it reflects both sides of my professional background. Before moving into tech and QA, I worked in the music industry in several roles, including DJ, radio DJ, journalist, retail marketing director for a record label, and independent promoter. QA has been my professional focus for the last several years, so this project felt like a natural way to combine my experience in software quality with a long-standing passion for music.

Using the TIDAL API allowed me to build a technical project that feels personally meaningful while still demonstrating practical API testing, automation, CLI execution, CI integration, and documentation skills.

API Reference

This project was designed and validated using the official TIDAL API reference:

• TIDAL API Reference

CI / Execution Flow

Project Goal

Build a small, well-documented API automation project in Postman that validates key TIDAL API endpoints and demonstrates QA skills in:

• test design
• API automation
• functional and negative testing
• integration flow validation
• documentation
• CLI and CI execution

Scope

In Scope

• OAuth2 Client Credentials token generation
• Smoke validation for core TIDAL API endpoints
• Functional validation of albums, artists, tracks, and search results
• Chained integration testing across related endpoints
• Negative and edge-case testing for invalid IDs and authorization failures
• Data-driven testing using a Postman data file
• Local execution with Postman CLI
• CI execution with GitHub Actions

Out of Scope

• User-authenticated OAuth flows
• Favorites, playlists, or collection management
• UI or mobile automation
• Load or performance testing beyond lightweight response-time checks
• Security testing beyond auth validation

Version 1 Coverage

The Postman collection is organized into four folders.

00_Smoke

Critical-path validation for token generation and endpoint reachability.

Requests:

• SMOKE-00: Fetch Client Credentials Token (Explicit)
• SMOKE-01: Albums Endpoint Reachable
• SMOKE-02: Artists Endpoint Reachable
• SMOKE-03: Tracks Endpoint Reachable
• SMOKE-04: Search Results Resource Reachable

01_Functional

Validation of response structure, required fields, and key relationships.

Requests:

• FUNC-01: Get Album by ID — Field Validation
• FUNC-02: Get Artist by ID — Field Validation
• FUNC-03: Get Track by ID — Field Validation
• FUNC-04: Search Results — Filter/Relationship Validation

02_Integration

Chained testing across related resources to confirm end-to-end API consistency.

Requests:

• INT-01: Search Results Resource Reachable
• INT-02: Get Search Result Artists — Extract Artist ID
• INT-03: Get Searched Artist Details
• INT-04: Get Artist Albums — Extract Album ID
• INT-05: Get Searched Album Details
• INT-06: Get Album Items — Chain Complete

03_Negative_Edge_Cases

Validation of error handling and authorization failures.

Requests:

• NEG-01: Invalid Album ID Returns 404
• NEG-02: Request Without Bearer Token
• NEG-03: Request With Invalid Bearer Token

What This Project Demonstrates

This project is designed to demonstrate:

• API authentication handling with bearer tokens
• JavaScript-based Postman test and pre-request scripting
• smoke and functional API validation
• response structure and field-level assertions
• relationship and data integrity checks across endpoints
• chained multi-step integration testing
• negative testing for invalid resources and invalid auth states
• data-driven execution with reusable test inputs
• clear test organization and documentation for portfolio presentation

Tools Used

• Postman
• Postman CLI
• Newman
• JavaScript (Postman test and pre-request scripts)
• GitHub
• GitHub Actions
• TIDAL API v2
• OAuth2 Client Credentials

Repository Structure

Environment Variables

The collection uses a Postman environment for configuration and runtime values.

Typical variables

• baseUrl
• clientId
• clientSecret
• accessToken
• tokenExpiry
• testAlbumId
• testArtistId
• testTrackId
• searchQuery
• searchArtistsLink
• searchedArtistId
• searchedAlbumId
• invalidAccessToken

Postman Authorization Setup

This collection uses a mix of request-level auth and scripted header injection.

Token request

SMOKE-00 uses Basic Auth with:

• clientId
• clientSecret

This request retrieves an access token and stores it in the environment for downstream requests.

Protected requests

Protected requests use a collection-level pre-request script to inject the bearer token manually using {{accessToken}}.

This approach makes the collection more reliable for local CLI and CI execution.

Negative auth requests

• NEG-02 is set to No Auth
• NEG-03 uses a request-level invalid bearer token

Important Setup Notes

Template vs local environment

This repository includes only a template Postman environment file.

Use a separate local environment file for real credentials and local runs. Do not commit real credentials, live tokens, or private environment files to GitHub.

How authorization is configured

• The token request uses Basic Auth with:
  • clientId
  • clientSecret
• Downstream API requests use a bearer token stored in:
  • accessToken

This setup allows the collection to reuse auth values across requests without hardcoding credentials in individual requests.

Important setup note

If collection-level authorization is configured with variables such as clientId and clientSecret, those variables must be populated in the active Postman environment before sending requests.

If either value is blank or missing, Postman cannot build a valid authorization header, which may cause token requests to fail with a 400 Bad Request or other authentication-related errors.

Recommended workflow

1. Select the correct Postman environment.
2. Confirm that clientId and clientSecret are populated.
3. Run SMOKE-00: Fetch Client Credentials Token.
4. Verify that accessToken is saved to the environment.
5. Run the remaining requests in the collection.

Negative auth requests

Two negative authorization tests are included in Version 1:

• NEG-02: Request Without Bearer Token
  • Set this request to No Auth at the request level.
• NEG-03: Request With Invalid Bearer Token
  • Use a request-level invalid token variable instead of inheriting the collection token.

This ensures the negative tests do not accidentally inherit valid authorization from the collection.

Postman environment export behavior

Postman exports shared values, not necessarily local-only values shown in the app UI. If a local export contains null values, populate a private local environment file manually for CLI execution.

Data-Driven Testing

Version 1 includes a small data-driven layer using a Postman data file:

postman/data/tidal-postman-test-data.json

This allows selected requests to run against multiple known-good test inputs and makes the suite more reusable and less dependent on a single hardcoded fixture.

Running the Collection in Postman

1. Import the collection JSON file.
2. Import the template environment file.
3. Create a private local copy of the environment.
4. Populate required variables, including clientId and clientSecret.
5. Run SMOKE-00 first to retrieve and store the access token.
6. Run the rest of the collection manually or with the Collection Runner.

Running the Collection Locally with Postman CLI

Example local run:

postman collection run tidal-postman-tests.postman_collection.json \
  --delay-request 250 \
  -e tidal-postman-environment.local.json \
  -d data/tidal-postman-test-data.json \
  --reporters cli,junit,json,html \
  --bail failure

Running the Collection Locally with Newman

Example local run:

newman run tidal-postman-tests.postman_collection.json \
  --delay-request 250 \
  -e tidal-postman-environment.local.json \
  -d data/tidal-postman-test-data.json \
  -r cli,json,junit,html \
  --reporter-json-export reports/newman-run-report.json \
  --reporter-junit-export reports/newman-junit-report.xml \
  --reporter-html-export reports/newman-html-report.html \
  --bail

Note: The Newman HTML output requires an external Newman HTML reporter.

Alternate Runner

In addition to Postman CLI, this collection can also be executed with Newman using the exported collection and environment files. This provides an alternate command-line runner and an additional CI-friendly execution path.

CI Execution

This project includes a GitHub Actions workflow that runs the Postman collection with Postman CLI on every push, pull request, and manual dispatch.

Required GitHub Secrets

• TIDAL_CLIENT_ID
• TIDAL_CLIENT_SECRET

Rate limiting note

A small delay is configured for automated collection runs to reduce the chance of rate limiting during multi-iteration CLI and CI execution. This was added after observing 429 Too Many Requests responses during GitHub Actions runs when the collection was executed too quickly across multiple data-driven iterations.

Reports

The workflow generates CLI, JUnit, JSON, and HTML reports during Postman CLI execution.

Generated report files include:

• postman/reports/junit-report.xml
• postman/reports/run-report.json
• postman/reports/run-report.html

During GitHub Actions runs, these files are created on the runner and uploaded as workflow artifacts. They are not automatically committed to the repository.

To view them in GitHub:

1. Open the repository
2. Click Actions
3. Open a workflow run
4. Download the postman-cli-reports artifact

For local Postman CLI runs, the same report files are written to the postman/reports/ folder.

Evidence

Project evidence includes:

• screenshots of passing collection runs
• screenshots of local CLI execution
• screenshots of GitHub Actions workflow runs
• sample reports or artifacts
• notes on debugging decisions and design changes
• representative Postman test and pre-request JavaScript snippets are included in the snippets/ folder to make the scripting layer more visible outside the exported collection JSON.

AI-Assisted Workflow

AI was used to help:

• refine collection structure
• improve test naming and organization
• strengthen negative and integration test design
• improve documentation
• support CLI and CI setup decisions

All final test logic, scope decisions, and request behavior were manually reviewed and validated.

Findings

A few notable findings from implementation:

• Similar TIDAL endpoints returned different response shapes depending on whether the request targeted a single resource or a filtered/list response.
• Search results required relationship traversal before a valid artist resource could be retrieved and validated.
• Postman CLI and GitHub Actions exposed auth and environment handling issues that were not obvious during manual Postman execution.
• Data-driven CI execution surfaced rate-limiting behavior, which was mitigated by introducing a small request delay.

Recent Enhancements

Since the initial Version 1 baseline, the project has been expanded to include:

• improved report publishing through GitHub Actions artifacts and workflow summaries
• a GitHub Actions status badge in the README
• Newman as an alternate command-line runner

Future Enhancements

Possible next steps:

• expand data-driven coverage
• add more endpoint coverage
• extend documentation with additional strategy, troubleshooting, and findings
• explore optional user-authenticated endpoint coverage in a later version

Notes

This repository is intended as a QA portfolio project and learning artifact. The suite is intentionally scoped to a clean Version 1 that is easy to understand, demo, and extend.