Updated 2 minutes ago

Share this article

Related News

Apple Watch Audio Intelligence: What Leaves Your Wrist and What Gets Saved

Oct 9, 2026

Apple Watch Audio Intelligence: What Leaves Your Wrist and What Gets Saved

Apple’s Live Rewind and Siri Recap use different routes through Apple Watch, a paired iPhone and Private Cloud Compute. Here is what gets processed, when nearby people are alerted and which text can persist.

Apple WatchApple Intelligenceprivacy

YouTube Custom Feeds Are Separate—Your Watch History Isn’t

Oct 9, 2026

YouTube Custom Feeds Are Separate—Your Watch History Isn’t

YouTube’s new Custom Feeds create focused tabs for a mood or interest. The tabs are separate from Home, but their viewing activity still enters standard watch history.

YouTubeAI recommendationsCustom Feeds

Meta Muse is coming to AI glasses. Its new connectors carry the bigger tradeoff

Sep 28, 2026

Meta Muse is coming to AI glasses. Its new connectors carry the bigger tradeoff

Meta announced Muse for AI glasses and expanded its connector roadmap at Connect 2026. The practical distinction is what is live, what is still coming and what account access can persist.

Meta MuseMeta Connect 2026AI agents

GitHub’s star-history API replaces identity-heavy pagination with weekly aggregates — Source: GitHub Docs / screenshot captured by OpenToolsSource image

Developer Platform

GitHub’s star-history API replaces identity-heavy pagination with weekly aggregates

By OpenTools Team

GitHub’s new repository star‑history endpoint returns weekly and daily aggregate counts, reducing large histories from thousands of identity‑bearing requests to a small trend dataset.

The endpoint returns trends without exposing every stargazer

GitHub’s new GET /repos/{owner}/{repo}/stargazers/history endpoint returns aggregate star activity by week and day. It replaces the common pattern of paginating through every user who starred a repository and reconstructing a time series locally.

The response is ordered newest‑first. Each week contains a total and daily counts beginning on Sunday. GitHub’s REST documentation warns that week boundaries are not guaranteed to align with UTC, so consumers should preserve the returned dates rather than inventing a timezone conversion.

The dataset reveals interest over time while avoiding an identity list in the trend response.

One call can return 30 weeks, with a 100‑page ceiling

The endpoint supports up to 30 weeks per request and a maximum page number of 100. Public repositories can be read without authentication. Fine‑grained tokens need Metadata read access.

GitHub’s engineering account says a React‑scale example fell from 2,511 requests to about 24. The exact savings depend on history length and page size, but the interface changes the unit of retrieval from individual users to time buckets.

That makes dashboards faster and reduces rate‑limit pressure. It does not create unlimited history: clients still need pagination and must handle the documented page ceiling.

GitHub moved the expensive grouping into an indexed date‑range query

GitHub says its first aggregate implementation still scanned millions of rows before grouping them. The production design instead performs indexed date‑range counts for the requested weeks, avoiding a full identity‑heavy history read for each request.

Exceptionally dense weeks remain a scaling edge case, according to the engineering post. Consumers should retain ordinary retry and backoff behavior rather than assuming every repository will respond with identical latency.

The architectural lesson is narrow: an aggregate endpoint can match the reader job better than exporting detailed records and discarding identities afterward.

Star history is an interest signal, not a conversion metric

GitHub describes stars as an approximate level of repository interest. A rising count can coincide with a release, conference talk or social post, but the API does not attribute the cause and does not report installs, active usage, retention or revenue.

Removed stars and historical corrections can affect totals. Use the returned values as GitHub’s current aggregate record, and label any before‑and‑after analysis with its time basis.

For product decisions, combine the series with repository traffic, package downloads or other qualified outcomes. Do not turn a visible line into a claim about adoption without supporting evidence.

Migration should preserve dates and delete unnecessary identity data

Replace stargazer pagination only where the job is trend analysis. Cache the aggregate response within an appropriate freshness window, preserve the returned date labels and validate a bounded interval against the previous series before removing old code.

If a pipeline collected user identities solely to draw a chart, stop retaining them after the aggregate migration. Keep identity‑bearing access only for a separately justified reader job and permission boundary.

Follow GitHub’s OpenTools organization page for material API changes.

Image: Real screenshot of GitHub’s official REST API documentation for starring and star history. OpenTools captured the source page without generative alteration or artificial upscaling.

Sources

1.github.blog (github.blog)
2.docs.github.com (docs.github.com)

Tags

GitHub APIrepository analyticsstar historydeveloper platformsprivacy