Query GitHub API with a GraphQL Query task

Pull structured data straight from GitHub without writing custom REST glue code. This blueprint calls the GitHub GraphQL API to fetch the 20 most recent closed issues in the kestra-io/kestra repository, returning each issue's title, URL, and first 5 labels in a single typed request. GraphQL lets you ask for exactly the fields you need and nothing more, so you avoid over-fetching and multiple round trips. Wrapping that call in a Kestra flow turns an ad hoc script into a versioned, schedulable, and observable pipeline you can extend into reporting, metrics, and downstream automation.

How it works

The flow runs a single task, get_github_issues, of type io.kestra.plugin.graphql.Request. It POSTs a GraphQL query to https://api.github.com/graphql with an Authorization: Bearer header built from {{ secret('GITHUB_TOKEN') }}. The embedded query targets the repository(owner: "kestra-io", name: "kestra") node and requests issues(last: 20, states: CLOSED), walking the edges and node structure to return each issue's title, url, and the first 5 labels. The task output holds the parsed JSON response, ready to be consumed by any subsequent task you add.

What you get

• The 20 most recently closed issues from kestra-io/kestra in a single response.
• Each issue's title, url, and up to 5 label names.
• A typed GraphQL request that fetches only the fields you ask for.
• A reusable, version-controlled starting point for GitHub data pipelines.

Who it's for

• Platform and DevEx engineers tracking repository activity.
• Engineering managers building issue and release reporting.
• Data engineers ingesting GitHub data into a warehouse.
• Anyone replacing brittle one-off API scripts with declarative flows.

Why orchestrate this with Kestra

The GitHub API has no built-in scheduler, no retry policy, and no execution history. Kestra adds all of it declaratively. Run the query on a schedule or fire it from an event trigger, attach retries and timeouts so transient API or rate-limit errors recover automatically, and get full execution logs and lineage for every run. Everything is plain YAML, so the query lives in Git alongside the rest of your pipelines instead of in an untracked cron job on someone's laptop.

Prerequisites

• A Kestra instance with the GraphQL plugin available.
• A GitHub account with access to the target repository.

Secrets

• GITHUB_TOKEN: a GitHub personal access token (or fine-grained token) with read access to the repository's issues.

Quick start

1. Add the GITHUB_TOKEN secret to your Kestra instance.
2. Copy this blueprint into a flow and adjust the namespace if needed.
3. Execute the flow manually and inspect the get_github_issues task output.
4. Confirm the returned issues, URLs, and labels match the repository.

How to extend

• Change owner and name in the query to point at your own repository.
• Swap states: CLOSED for OPEN, or query pull requests, releases, or discussions.
• Add a Schedule trigger to refresh the data on a cadence.
• Pipe the output into a database, Slack message, or DuckDB query for analysis.
• Paginate with after cursors to pull more than 20 issues.

Links

• Plugin docs: https://kestra.io/plugins/plugin-graphql