How do their APIs compare?

These two projects have fundamentally different notions of "API," since one is a data/content repository and the other is a state-management library.

iptv-org/iptv: a data-export "API"

iptv-org/iptv doesn't expose a programmatic API in its own codebase — the README explicitly says API documentation lives in the separate iptv-org/api repository. What lives in this repo is the machinery that builds the underlying playlist/channel data and republishes it:

• scripts/api.ts builds an in-memory data layer using @iptv-org/sdk models (categories, countries, channels, feeds, blocklist records, guides, etc.), all indexed via Dictionary/Collection helpers from @freearhey/core [scripts/api.ts:L1-L23]. It exposes a searchChannels(query) function that runs a search index and resolves matching IDs back to Channel objects [scripts/api.ts:L140-L154], and exports data, loadData, downloadData, and searchChannels [scripts/api.ts:L156].
• The GitHub Actions update workflow (.github/workflows/update.yml) is really the "API surface" consumers rely on indirectly: it runs playlist:update, playlist:lint, playlist:validate, playlist:generate, and playlist:export to produce .api/streams.json, which is then pushed into the iptv-org/api repo [.github/workflows/update.yml:L30-L75].
• End users interact with the "API" as static file URLs (e.g., https://iptv-org.github.io/iptv/index.m3u, or per-source playlists) rather than as function calls — see the README and .readme/template.md [.readme/template.md:L71-L89].

So iptv-org/iptv's "API" is essentially a generated, versioned data artifact (JSON/M3U playlists) plus a thin internal search/query helper (scripts/api.ts), not a request/response service defined in this repo.

statelyai/xstate: a programmatic state-machine API

xstate's API is a proper TypeScript library surface for defining and running state machines/actors. From the retrieved chunks:

• Schema-level API contract: packages/core/src/machine.schema.json defines the JSON Schema for machine configs — state node types (atomic, compound, parallel, final, history), transitions, actions, and initial-transition objects [packages/core/src/machine.schema.json:L1-L40, L141-L215, L281-L320]. This is effectively a formal spec for the shape of machine definitions that the library's public config API accepts.
• Runtime equality/comparison helpers used internally by the public API: areStateNodeCollectionsEqual for comparing state node sets during transition resolution [packages/core/src/stateUtils.ts:L967-L981], and stateValuesEqual for comparing StateValues recursively in the testing/graph tooling [packages/core/src/graph/TestModel.ts:L321-L345].
• Framework-binding APIs: packages/xstate-react exposes React-specific hooks like useSelector, which relies on a defaultCompare (===) function for memoization [packages/xstate-react/src/useSelector.ts:L9-L12], and a shallowEqual utility for comparing selector outputs by shallow key comparison [packages/xstate-react/src/shallowEqual.ts:L10-L38].

Comparison

• Nature: iptv-org/iptv's API is data-oriented and file/artifact-based (playlists, JSON exports); xstate's API is code-oriented — types, schemas, and functions consumed directly in application code.
• Consumption model: iptv-org/iptv consumers fetch static URLs or use the separate iptv-org/api/@iptv-org/sdk packages; xstate consumers import machine/actor primitives and hooks (e.g., useSelector) directly into their app.
• Validation approach: iptv-org/iptv validates its data via lint/validate scripts in the update pipeline [.github/workflows/update.yml:L36-L38]; xstate validates machine configuration shape declaratively via JSON Schema [packages/core/src/machine.schema.json:L1-L40].
• Internal support code: Both repos rely on equality-comparison utilities, but for different purposes — iptv-org/iptv's