Platform Documentation
LTTV API
Internal documentation for the API that connects the LTTV website, mobile application, admin panel, streaming services, Cloudflare infrastructure, and Google services.
Overview
Purpose
The API provides a shared server-side interface between LTTV clients and external services.
Public website pages, the mobile application, and future administrative tools can use the API without connecting directly to every external platform.
The current implementation uses Express and ES modules. It can run locally through Node.js or be imported by the Cloudflare Worker entry point and exposed through the Worker runtime.
Current responsibilities include live stream detection, stream-source selection, public configuration, provisional calendar data, and member check-in backed by Google Sheets.
Architecture
High-level request path
Client requests enter through the Cloudflare Worker and are passed to the Express application.
worker.js
server.js
Current Implementation
API capabilities
Capabilities represented in the currently supplied API source files.
Combined live status
Checks available stream platforms and returns the selected primary source.
View endpoint documentation →Cloudflare Stream
Determines whether the configured direct live input is currently connected.
View integration documentation →YouTube live detection
Checks the configured YouTube channel for an active live broadcast.
View integration documentation →Twitch live detection
Checks the Twitch Helix API for the configured channel.
View integration documentation →Member check-in
Validates member IDs and submits attendance lists through Google Sheets.
View check-in documentation →Calendar response
Returns placeholder event data pending a permanent calendar source.
View calendar documentation →HTTP Interface
Current endpoints
Current routes use the
/api base path.
| Method | Path | Purpose | Status |
|---|---|---|---|
| GET |
/api/config
|
Returns safe client-visible configuration. | Implemented |
| GET |
/api/liveStatus
|
Returns combined stream status and the selected primary source. | Implemented |
| GET |
/api/directLive
|
Returns direct Cloudflare Stream live-input status. | Implemented |
| GET |
/api/youtubeLive
|
Returns YouTube live status for the configured channel. | Implemented |
| GET |
/api/twitchLive
|
Returns Twitch live status for the configured channel. | Implemented |
| GET |
/api/calendar
|
Returns provisional upcoming event data. | Provisional |
| POST |
/api/check-in/validate-member
|
Checks whether a member ID is included in the whitelist. | Implemented |
| POST |
/api/check-in/submit-list
|
Validates and writes a member check-in list. | Implemented |
Streaming
Default source priority
When multiple platforms are live, the API selects a primary stream using the configured source order.
-
1
Cloudflare Stream
Preferred direct stream when its live input is available.
-
2
YouTube
Used when the direct Cloudflare source is unavailable.
-
3
Twitch
Used when neither Cloudflare Stream nor YouTube is available.
Operations
Configuration summary
Configuration is divided between
wrangler.toml, environment
variables, Cloudflare secrets, and bound
Cloudflare resources.
Worker configuration
- Worker name
-
lttv-app-api - Worker entry point
-
worker.js - Compatibility date
-
2026-02-13 - Compatibility flag
-
nodejs_compat - Dashboard variables
-
Preserved with
keep_vars = true
Cloudflare resources
- D1 binding
-
EVENTS_DB - D1 database name
-
lttv-events-db - Secret values
- Managed through Cloudflare and intentionally excluded from the wiki
Continue Reading
API documentation sections
Detailed pages for the API architecture, routes, integrations, source files, and deployment process.
Architecture
Worker bridge, Express application, external integrations, caching, and data flow.
Endpoints
Request parameters, payload validation, response objects, and status codes.
Integrations
Cloudflare Stream, YouTube, Twitch, Google OAuth, and Google Sheets.
Source Modules
Responsibilities and relationships for each JavaScript source file.
Configuration
Wrangler settings, variable names, secrets, CORS, and resource bindings.
Deployment
Local development, Wrangler testing, deployment, and post-deployment checks.
Maintenance Notes
Current implementation notes
Known characteristics of the currently supplied API implementation.
- The calendar endpoint currently returns provisional data rather than using the planned event source.
-
The D1 database is bound as
EVENTS_DB, but not every API feature currently uses it. - Member check-in data is stored through Google Sheets rather than D1.
- Runtime caching should be treated as process-local unless a shared persistent cache is explicitly added.
- The current package configuration does not include an implemented automated test suite.