GitHub repo — stars / forks / issues

You're maintaining a competitor-tracking sheet, doing OSS due diligence on a hire's prior work, or just curious how a project's star count moved this month. Loading github.com repo pages and squinting at the header counters is fine for one repo, painful for ten. This template hits GitHub's public REST API directly, pulls the canonical numbers (stars, forks, open issues) for any owner/repo, and logs them. No login, no API key, no DOM scraping — just a clean JSON response.

How this workflow works

Three blocks. This is one of the shortest useful workflows you can build, and a good first example if you're learning how HTTP requests work inside the extension.

1. manual_trigger — Run button in the sidepanel. Exposes two inputs: owner (default AutomaApp) and repo (default automa). When you press Run, a small prompt appears asking you to confirm or change those two values.
2. http_request — A GET against https://api.github.com/repos/{{vars.input.owner}}/{{vars.input.repo}}. The header Accept: application/vnd.github+json is GitHub's recommended way to pin the response to the current API version. timeoutMs: 10000 aborts after 10 seconds; responseType: "json" tells the block to parse the body as JSON, exposing it as $('GET repo metadata').body.
3. log_data — Builds a one-line summary using template interpolation: "{{owner}}/{{repo}} — stars=… forks=… open_issues=…". The block writes this to the workflow log with label github, visible in the sidepanel run history.

GitHub's API is fast (typically <300 ms) and well-documented. The fields used here (stargazers_count, forks_count, open_issues_count) are part of the standard repository object schema and have been stable since the API's v3 release.

Customising it for your case

A few directions worth taking this template.

• Pull more fields. The same body object exposes pushed_at (last push timestamp), language (primary language), default_branch, license.name, subscribers_count (watchers), and description. Edit the log_data.source string to interpolate any of them: {{$('GET repo metadata').body.language}}.
• Authenticated mode (higher rate limit). Unauthenticated requests are capped at 60 per hour per IP. Add an env variable GITHUB_TOKEN (Settings → Env), then add a header {"key": "Authorization", "value": "Bearer {{env.GITHUB_TOKEN}}"}. You get 5,000 requests/hour with a personal access token.
• Loop over a list. Replace the manual_trigger inputs with a set_variable block holding an array of owner/repo strings, then a loop block iterating that array. Each iteration hits the API with different values — handy for a daily dashboard of 20 repos.

Common gotchas

The free GitHub API has a 60 req/hour limit per IP for unauthenticated requests. If you're sharing a VPN or office NAT with other developers, you may hit the cap unexpectedly — the response will be 403 with a rate-limit-remaining: 0 header. Add a token (see above) and the limit jumps to 5,000. Second pitfall: private repos return 404 rather than 403 to unauthenticated requests, which can be confusing. Third: forks have their own counts independent of the upstream — querying microsoft/vscode-fork won't give you Microsoft's main repo numbers.

FAQ

Do I need a GitHub account or token? No, for read-only queries against public repos. The default manual_trigger defaults (AutomaApp/automa) work without any auth setup. Tokens become necessary if you're running this on a schedule or batching multiple repos.

Will this work for GitLab, Bitbucket, or Codeberg? Not as-is. Each platform has its own API shape. The pattern is identical though: swap the URL to https://gitlab.com/api/v4/projects/<id> and read different fields. Same http_request + log_data structure.

How is this different from Automa's HTTP block? Functionally identical for this use case. Automa, Browserflow, and Bardeen all support HTTP requests with env vars and JSON body parsing. BNOD's slight edge: the $('Step Name').body.field grammar avoids referring to steps by index, which makes the workflow survive insertions and reorders.