GitHub Node

The GitHub node adds native GitHub REST operations to a workflow, similar to the multi-operation GitHub nodes you may know from tools like n8n.

The GitHub node adds native GitHub REST operations to a workflow, similar to the multi-operation GitHub nodes you may know from tools like n8n.

Overview

PropertyValue
Inputs1
Outputs1
CredentialGitHub
Output$nodeLabel.*

Supported Operations

The node currently provides 40 actions:

ResourceActions
RepositoryGet Repository, Get Repository License, Get Repository Profile, Get Repository Issues, Get Repository Pull Requests, List Popular Paths for Repository, List Top Referrers for Repository
Organization / UserList Organization Repositories, List User Repositories, Get User Repositories, Get User Issues, Invite User
IssueCreate Issue, Get Issue, List Issues, Edit Issue, Lock Issue, Create Comment
Pull requestCreate Pull Request, List Pull Requests
ReviewCreate Review, Get Review, List Reviews, Update Review
ReleaseCreate Release, Get Release, List Releases, Update Release, Delete Release
WorkflowList Workflows, Get Workflow, Enable Workflow, Disable Workflow, Get Workflow Usage, Dispatch Workflow, Dispatch Workflow and Wait
FileGet File, List Files, Create or Update File, Delete File

Credential

Create a GitHub credential in the Credentials Tab with:

  • A personal access token
  • Optional full REST API base URL for GitHub Enterprise Server

Leave the base URL empty for GitHub.com. Fine-grained PATs are recommended.

For GitHub Enterprise Server, enter the complete REST API endpoint including /api/v3, such as https://github.example.com/api/v3. Do not enter only the web UI root (https://github.example.com).

If you use GitHub Enterprise Server and later edit the credential to rotate the token, leaving base_url empty preserves the existing Enterprise endpoint. Enter a new URL only when you want to change that endpoint.

Common Fields

Most operations use:

  • Owner – Repository owner, organization name, or username
  • Repository – Repository name

List Organization Repositories only requires Owner (the organization name) and does not use the repository field.

List User Repositories only requires Owner (the username) and does not use the repository field.

Get User Repositories mirrors n8n's User → Get Repositories action. Get User Issues returns issues assigned to the authenticated GitHub user by default. Set Mentioned Filter to any non-empty value to return issues mentioning the authenticated user instead. It also supports state, labels, updated-since, sort, direction, and per-page filters. Invite User requires an organization and email address and does not use Owner or Repository.

Repository

Repository operations include metadata, detected license content, community health profile, and traffic insights. List Popular Paths for Repository and List Top Referrers for Repository return GitHub's top traffic entries for the last 14 days and require repository administration push access.

List Issues supports optional assignee, creator, mentioned user, comma-separated labels, updated-since timestamp, sort, and direction filters. List Pull Requests supports state, sort, direction, and per-page controls.

Get Repository Issues and Get Repository Pull Requests expose the same APIs as their List counterparts under explicit n8n-compatible repository action names.

Get Repository metadata

Get Repository stores GitHub's complete response in $github.repository and also exposes $github.full_name, $github.default_branch, $github.private, and $github.url.

The repository payload commonly includes:

  • Identity and ownership: ID, name, full name, description, owner, and visibility
  • Repository state: private, fork, archived, disabled, and default branch
  • URLs: GitHub page, API, clone, SSH, and Git URLs
  • Activity and size: creation, update and push timestamps, size, stars, watchers, forks, subscribers, and open issues
  • Features: issues, projects, wiki, Pages, discussions, topics, language, and homepage
  • License, merge settings, caller permissions, security settings, and fork parent/source metadata when available

Some administrative, permission, merge, and security fields depend on the credential's repository permissions.

Example:

  • Owner: heymrun
  • Repository: heym

Issues

Issue operations support title/body fields and optional JSON-array fields for labels and assignees.

List Issues returns repository issues only. Pull requests are excluded; use List Pull Requests for PR results.

["bug", "backend"]
["octocat"]

Edit Issue field semantics

For Edit Issue, only fields you explicitly set are sent to GitHub:

  • State – Choose Don't change, Open, or Closed. Leave unset to keep the current state.
  • State Reason – Optionally set Completed, Not Planned, Duplicate, or Reopened.
  • Title / Body – Leave blank to keep the current value.
  • Labels / Assignees – Leave the field empty to keep the current value. Use [] to clear all labels or assignees. Use a JSON array such as ["bug"] to replace them.

Edit Issue requires at least one field to change at runtime. If you only provide an issue number, execution fails with a validation error from the GitHub API layer.

Lock Issue

Lock Issue accepts an optional Lock reason. When provided, it must be one of GitHub's supported values:

  • off-topic
  • too heated
  • resolved
  • spam

Leave the reason empty to lock without a specific reason.

Pull Requests

Create PR requires:

  • Title
  • Head branch
  • Base branch
  • Optional body
  • Optional draft mode

Pull Request Reviews

Review operations match GitHub's pull request review API:

OperationRequired fieldsOptional fields
Create ReviewPull request number, eventBody, commit ID
Get ReviewPull request number, review ID—
List ReviewsPull request numberPer page
Update ReviewPull request number, review ID, body—

Create Review supports Approve, Request Changes, Comment, and Pending. The body is required for Request Changes and Comment. When Commit ID is empty, GitHub reviews the pull request's latest commit.

Releases

OperationRequired fields at runtimeCommonly optional
Create ReleaseTag nameRelease name (title), body, target branch, draft, prerelease
Update ReleaseRelease IDTag name, release name, body, target branch, draft, prerelease
Get Release / Delete ReleaseRelease ID—

Update Release can explicitly set draft / prerelease to either true or false.

Workflows

Workflow operations support:

  • Listing repository workflows
  • Getting a workflow by numeric ID or workflow file name
  • Enabling or disabling a workflow
  • Reading billable workflow usage by runner operating system
  • Dispatching a workflow with a ref or branch plus optional JSON inputs object

GitHub is in the process of closing down the Get Workflow Usage endpoint. Workflows using this operation may need to migrate when GitHub removes the endpoint.

Dispatch Workflow accepts both GitHub response forms: legacy 204 No Content and the newer 200 response containing workflow_run_id, run_url, and html_url.

Dispatch Workflow and Wait dispatches the workflow and polls the run until its status is completed. Configure the timeout and polling interval in seconds. Heym uses workflow_run_id when GitHub returns the newer 200 response. For the traditional 204 No Content response, Heym discovers the newly created workflow_dispatch run for the selected workflow and ref, then waits for that run.

File Contents

Get File reads a repository file through GitHub's contents API and decodes text content when available. Binary files and non-UTF-8 content may return metadata without a decoded content field.

List Files returns directory entries from the repository contents API for a given folder path and optional ref. Leave Directory Path empty to list the repository root.

Create or Update File writes text content to a repository path using:

  • File path
  • Commit message
  • File content
  • Optional branch

Delete File removes a repository path using a commit message and optional branch. If the file exists, Heym fetches the current SHA automatically before deleting it.

If the file already exists, Heym fetches the current SHA automatically before updating it.

Pagination

List Issues, Get Repository Issues, Get User Issues, List Pull Requests, Get Repository Pull Requests, List Reviews, List Releases, List Workflows, List Organization Repositories, List User Repositories, and Get User Repositories support Per Page (1–100). Each run returns one page of results. To read further pages, use the Cursor field.

Every list operation adds two fields to its output:

  • has_more: true when GitHub reports another page after this one.
  • next_cursor: an opaque value to pass back as Cursor, or null on the last page.

Leave Cursor empty for the first page. To continue, set it to the next_cursor of the previous run (for example a value your workflow received as input or kept in a Variable) and stop when has_more is false. Cursor accepts expressions, and a value that did not come from next_cursor is rejected with an error before any request is sent.

Use has_more rather than comparing count with Per Page to detect the last page. List Issues removes pull requests from each page after GitHub returns it, so a full page can come back with fewer items than Per Page (16 of 100 on a repository with many pull requests) and still have more pages after it. GitHub also limits page-based paging on some issue lists to the first 1,000 items; next_cursor switches to GitHub's cursor pagination there, so it keeps working past that point.

Return all pages

Turn on Return all pages to have one run follow every page, starting at Cursor when one is set. Each request asks for 100 items, whatever Per Page says. The node stops after about 1,000 items (or 100 requests): issue objects are around 6 KB each, so a larger cap would produce very large node outputs. When it stops early it returns what it has with has_more: true and a next_cursor instead of raising an error, and you can continue by passing that cursor to the next run. Stopping the workflow, or hitting the workflow timeout, ends the fetch between pages.

Output

The exact shape depends on the selected operation. Common fields include:

  • $github.success
  • $github.operation
  • $github.repository
  • $github.license
  • $github.profile
  • $github.paths
  • $github.referrers
  • $github.issue
  • $github.issues
  • $github.pull_request
  • $github.pull_requests
  • $github.review
  • $github.reviews
  • $github.release
  • $github.releases
  • $github.workflow
  • $github.workflows
  • $github.workflow_run
  • $github.workflow_run_id
  • $github.completed
  • $github.conclusion
  • $github.usage
  • $github.billable
  • $github.invitation
  • $github.file
  • $github.items
  • $github.path
  • $github.sha
  • $github.commit_sha
  • $github.deleted
  • $github.created
  • $github.ref
  • $github.inputs
  • $github.has_more (list operations)
  • $github.next_cursor (list operations)

Replace github with your node label.

Notes

  • Labels and assignees must be valid JSON arrays when provided.
  • Workflow dispatch inputs must be a valid JSON object when provided.
  • Edit Issue uses state only when you explicitly set it; leave it unset to keep the current issue state.
  • GitHub API permissions depend on the token scopes or fine-grained repository permissions you grant.