Theatrical
2026SDK design · Typed API contracts · An event bridge · Three languages
Cinema ticketing runs on production-grade APIs with no developer ecosystem around them: no typed clients, no components, no events. Theatrical is that layer — type-safe SDKs in TypeScript, C# and Python, an event bridge that turns request-response snapshots into a typed event stream, a CLI and React components — published on npm, NuGet and PyPI.
Treat cinema-going as infrastructure
Sessions, seats, orders, loyalty, pricing, food and beverage: an industry’s worth of ticketing sits behind good APIs, and every developer who builds on them starts from zero. Theatrical asks what that would feel like with the developer experience payments and commerce have spent a decade perfecting: one coherent, typed surface you can hold.
Eight resources, decided before a line was written
Each resource is a noun from the cinema domain, and the verbs are where the thinking shows: an order isn’t just created, it gains tickets and items, takes loyalty, is confirmed, completed, cancelled or refunded. Every response is parsed against a runtime schema before it reaches your code, so a field the platform changes fails loudly at the boundary instead of quietly downstream.
A snapshot API, turned into events
The platform APIs it targets are request-response: you ask what is true and get a snapshot. The event bridge polls each resource on its own loop — orders every 5 seconds, sessions every 10, films every 60, never overlapping a slow request — diffs each read against the last, and emits typed events: booking.created, booking.confirmed, booking.cancelled, session.updated, session.soldout, inventory.low and the rest.
Webhooks are signed with HMAC-SHA256 and verified with a constant-time comparison, with an optional replay window. Delivery retries with exponential backoff, and every endpoint is delivered to independently, so one failing receiver never blocks the others.
The details you notice only when they’re missing
Token refresh runs five minutes before expiry, and concurrent refreshes collapse into one. Backoff uses full jitter and honours Retry-After, including its HTTP-date form. A sliding-window limiter keeps a client under the platform’s rate limits, and a typed error hierarchy means a rate limit is something you can catch and reason about. Path parameters are encoded as a single segment, so an id can never become a path.
One surface, in each runtime’s own idiom
The booking front end is TypeScript; the back office is .NET; the data work is Python. So the same surface is ported three times, each written the way that language’s developers expect, and each with its own suite. The Python port is type-checked in strict mode.
| Package | Runtime | Tests |
|---|---|---|
| @theatrical/sdk | TypeScript 5.9 | 280 |
| @theatrical/cli · events · react · analytics | TypeScript 5.9 | 389 |
| Theatrical.Sdk | C# / .NET 8 | 276 |
| theatrical | Python 3.10+ | 339 |
The same data, three readers
The demo runs a simulated cinema through the event bridge and shows it three ways: to an audience, to an operator, and to a developer.
Tonight’s sessions with seats filling, on a simulated cinema.
Admissions, occupancy and the event stream announcing what just changed.
The SDK and component code each view is built from, shown beside it.
Install it, or read it
The SDKs are MIT. Advanced tooling is BSL 1.1, converting to MIT on 7 April 2030, or sooner on a version’s fourth anniversary.