Developer data-layer concept · no endpoint is live
See what trustworthy
reward data should include.
StreamData is the planned developer layer for bounded, normalized Stream Empire data. This static prototype uses a frozen sanitized compatibility fixture; it does not serve an API or current platform state.
4Sample campaigns
6Sample rewards
3Sample games
0Live endpoints
Sanitized fixture counts · observed · not current coverage.
Field-level trust
A value without its evidence
is only a claim.
Source, observed time, validation, conflict, retraction, display rights, and freshness belong to each field—not just the row.
- Source surface
- Twitch public Drops surface
- Observed
- Fixture state
- Historical sample · current state not asserted
- Public output
- Safe projection proposed; raw envelopes stay private
One developer layer, clear product owners
planned boundary
{}StreamDatadocuments and may eventually serve bounded normalized datareference →
🎁StreamDropscampaign requirements, deadlines and claim guidanceconsumer view →
◎StreamBadgesbadge identity and acquisition guidanceconsumer view →
◈StreamEmotesemote meaning and provider-identity conceptconsumer view →
▤StreamerDatabasecreator profile and discovery conceptprofile view →
⌁StreamAlertperishable reward events and future RSS deliveryevent view →
▦StreamOverlaysreward-aware OBS utilities and creator deliverycreator view →
Launch gate
Fail closed until API-001 defines the public contract.
Resource shapes, errors, filters, pagination, limits, cache behavior, CORS, versioning, corrections, monitoring and consumer terms remain undecided. Proposed API paths therefore have no endpoint. Any deployed prototype must preserve genuine 404 responses instead of serving static HTML that pretends to be a service.