D&D Character Sheet API — Concurrent Client

Working with REST APIs professionally means learning things that don't show up in tutorials, how to handle auth token lifecycles, how to structure retry logic. How to manage concurrent request dispatch responsibly without hammering an endpoint into rate limiting or getting an IP banned. That knowledge accumulates on the client side of real integrations, and it does not come with a public repository attached. This client exists to close that gap. It is a controlled concurrent client built against the companion character sheet API, a server built specifically to be hammered, on infrastructure that belongs to the same person running the hammer. That matters. Demonstrating high-throughput client behavior against a public third-party API is not a responsible option. Owning both sides of the contract makes it one.

Current Focus

The backend API is being finalized. A prototype script is validating the request and response contract before full client implementation begins. The client is designed and imminent.

Current State

Design is complete. Implementation begins once the backend reaches a stable state worth hammering.

What's Planned

The client authenticates via token exchange, constructs structured POST requests against the API's defined body contract, and dispatches up to 50 concurrent threads. That ceiling is intentional, enough to surface real concurrency behavior and meaningfully stress the server, not enough to simulate a denial of service. The behavior reflects how real API consumers operate when they share infrastructure and cannot simply maximize throughput without consequence. Beyond raw request dispatch, the client ingests the JSend response envelope, extracts the character sheet payload from each successful response, transforms and aggregates the data, and loads the results into PostgreSQL. The aggregation layer produces meaningful output, class and level distributions, statistical summaries across the full generated dataset. A run summary covers requests sent, success and failure rates, and response time distribution under concurrent load. The end result is a demonstrable data engineering pipeline with queryable output, not a script that exists to generate throughput numbers.

How It's Built

Python with a thread pool handling concurrent dispatch. Authentication against the token-based auth layer of the companion API. JSend envelope parsing, payload extraction, transformation and aggregation, and a PostgreSQL load step completing the pipeline. The client and backend are separate repositories, each self-contained, but designed to be read alongside each other.