Summary
The TestFlight Watcher provides a simple catalog of public TestFlight links that can be consumed via the rsch.io API and surfaced in Research Labs or other internal tools.
It periodically crawls and normalizes metadata for selected TestFlight apps, then exposes that data via a read‑only API endpoint.
What it tracks
For each TestFlight entry, the watcher keeps the following public fields:
- name – Human‑readable application name (for example,
Microsoft Edge). - category – Logical grouping for the app, currently
ios_app. - url – The public TestFlight invitation URL.
- status – Boolean flag indicating whether the entry is considered active.
- available - Describes the current availability condition of the entry. Possible values
are
Yes(The entry is available and open for processing),Full(The entry exists but capacity is full (not available for new users).),No(The entry is currently unavailable), orDelete(The entry has been removed or is no longer valid). - last_update – Date string indicating when the entry was last refreshed in the watcher (newest entries are returned first).
The underlying MongoDB document may contain internal fields such as _id or
last_seen_at, but these are never exposed in the public API response.
Typical use cases
- Building a TestFlight directory in Research Labs where users can quickly discover useful beta apps.
- Embedding the data into internal dashboards or tooling without having to touch the underlying MongoDB cluster.
- Automating checks that rely on a curated list of TestFlight apps (for example, QA or mobile‑testing workflows).
Data freshness
The watcher sorts results by last_update in descending order, so newer or
recently‑seen apps appear first in the list. How often the underlying data is
refreshed depends on your scheduler / cron setup for the watcher job.
The API itself is strictly read‑only; clients cannot modify or remove entries through this endpoint.