Products
One schedule, and every way in and out of it
The hub holds one canonical record per game. The products are the routes into it and the routes back out — and you only ever integrate with one of them.
The shape of it
Everything here is the same idea seen from a different side. Sources send **observations** — what one source says about one game. The hub resolves those claims into a canonical fixture and records which observation won each field. Consumers read that fixture, subscribe to what changes, or embed it.
What that buys you is narrow and worth stating plainly: you stop maintaining N integrations, and you stop guessing which of two conflicting kickoff times is right. The answer is in the response, with its source attached.
An API meant to be consumable by anyone
The hardest part of an interchange is not the data model, it is being easy enough to adopt that people actually do. So: one open spec, one base URL, one header. Everything is snake_case, every id says what it is, every error is an RFC 9457 document whose type URI resolves to a page explaining that exact error.
Test mode is a complete copy of the API over a partition you can wipe, and going live is a key swap. A club with no engineers pastes a calendar URL; a platform with a team pushes batches. Both end up in the same canonical record.