Overview
I created a Postman workflow for token-based API testing with dependent requests, chained execution, and response validation for a public SlotsOne API sample.
The public evidence page is pyavchik.space/postman-tests.html. It presents 57 API tests with coverage across Auth, Happy Path, Negative, Security, Wallet, EU Roulette, US Roulette, Book of Dead, and Provably Fair.
The runnable Postman collection is public at /postman/slots-collection.json. The collection contains grouped flows for Auth, Slots Game, Wallet, History & Provably Fair, Roulette, American Roulette, Book of Dead, and Negative Tests. It uses automated assertions and chained variables rather than isolated one-off requests.
From the collection itself, there is visible automation evidence: 178 pm.test assertions, 292 pm.expect checks, and 53 pm.collectionVariables.set operations. Variables such as access_token, session_id, game_id, spin_id, round_id, current_balance, and client_seed are passed between related requests to keep the scenario stateful.
The related API contract is documented publicly at pyavchik.space/api-docs/. The Swagger / OpenAPI documentation exposes the real endpoints, request and response schemas, JWT bearer authentication flow, token refresh behavior, and parameters such as Idempotency-Key. It also shows both production and local development servers.
The database side is documented at pyavchik.space/sql.html. This public PostgreSQL-oriented SQL reference includes an ERD-style schema view, 30 query references, migrations, indexes, transactions, connection-pool details, token-rotation logic, and examples of CREATE TABLE, SELECT, INSERT, UPDATE, and DELETE operations. It helps show how API behavior relates to stored data and backend persistence rules.
The suite demonstrates practical API QA work instead of generic Postman familiarity:
- Functional API test cases for register, login, refresh, logout, init, spin, wallet, history, and provably fair flows
- Multi-step scenarios where one request provides the token, session, round, or balance state required by the next request
- CRUD-style coverage through create/init flows, retrieval of history and round details, updates to client seed and balance-related state, and token revocation/logout behavior
- Negative checks such as missing authorization, insufficient balance, invalid body, and duplicate idempotency key
- Security-oriented checks such as IDOR, SQL injection, XSS payload handling, and rate limiting
- Evidence of token and environment handling, downloadable collection usage, Newman-oriented execution guidance, contract review against Swagger/OpenAPI docs, and SQL-aware validation of data and persistence assumptions
I used the API documentation to design coverage, validate request/response expectations, and keep the Postman suite aligned with the actual backend contract instead of testing blind. The SQL reference strengthens the same case by showing that I can reason about schema design, database constraints, and what should be verified beyond the HTTP response body.