GitHub integration

What it does

The GitHub integration lets you run developer-workflow automations on behalf of any repository you have access to. Connect a Personal Access Token once, then open issues, trigger GitHub Actions workflows, and list pull requests from any workflow step. Four real-time triggers let you react the moment an issue changes, a pull request moves through review, commits land, or a release is published.

GitHub lives under the Developer Tools category. You can also find it by searching for git.

This integration uses a GitHub Personal Access Token (PAT), not OAuth. There is no "Sign in to GitHub" button and no consent screen. The connection is a single field where you paste a token.

Connect a GitHub account

The connection holds one credential: a Personal Access Token. The webhook signing secret for triggers is configured separately, per trigger, when you publish a workflow. For the general connect flow across all apps, see Connect an account.

1. Generate a token in GitHub

   Create a fine-grained PAT at https://github.com/settings/personal-access-tokens, or a classic PAT at https://github.com/settings/tokens. Scope it to the minimum permissions your workflows need, for example read and write on Issues, Pull requests, and Contents for the target repositories.

2. Paste it into the connection

   In TaskJuice, open the GitHub connection and paste the token into the Personal Access Token field.

3. Save the connection

   TaskJuice stores the token encrypted. It is never shown again after you save, so keep a copy in GitHub if you need to reference it later.

To revoke access, delete the PAT from https://github.com/settings/tokens. Because access is scoped to the token, switching the acting account means generating a new PAT and rotating it into the connection. For credential lifecycle details, see Connections.

Triggers

Every trigger is a real-time webhook. Each inbound delivery is one event and produces one activation. There is no polling and no batch or digest collapse.

Issue, pull request, and release events each fire across many sub-actions. The specific lifecycle transition arrives in the action field of the output, so add a Branch or Switch node downstream and filter on it, for example action == "opened". See Triggers and actions.

Output keys per trigger

For Issue Event, installation can be null. For Push Event, commits is an array and head_commit can be null.

Verifying inbound deliveries

Each GitHub trigger verifies every delivery against an HMAC-SHA256 signature in the X-Hub-Signature-256 header. When you publish a trigger, TaskJuice gives you a signing secret. Paste it into the GitHub webhook's configuration under Secret. GitHub signs the request body with HMAC-SHA256 and sends the digest in X-Hub-Signature-256. Deliveries whose signature does not match are rejected.

Actions

All three actions send authenticated HTTP requests using the token from your connection. The owner and repo fields are free text: type them directly or map them from an upstream step. There is no repository or owner dropdown.

Create Issue

Creates a new issue. Requires owner, repo, and title.

Output keys: id, number, url, html_url, state, title, body.

Create Repository Dispatch

Sends a repository_dispatch event that GitHub Actions workflows can listen for. Requires owner, repo, and event_type.

A successful dispatch returns no body. There is no output to map downstream.

List Pull Requests

Lists pull requests for a repository. Requires owner and repo. Returns an array, not a single pull request.

Each item in the returned array has these keys: id, number, state, title, url, html_url.

Errors

When a GitHub request fails, the step's top-level error code is UPSTREAM_REQUEST_FAILED. The provider's HTTP status maps to a specific TaskJuice error code:

For how a paused or failed run recovers, see Run and step statuses and Reconnect an integration.

Known limitations

• Authentication is a Personal Access Token, not OAuth. Access is limited to the scopes and permissions you granted the token. A 404 on a repository that exists usually means the PAT cannot see it. Switching the acting account means generating a new PAT and rotating the connection.
• PATs expire. Fine-grained and classic tokens can carry an expiry. When one lapses, requests return 401, surfaced as auth expired. Rotate the token to restore the connection.
• Provider rate limits apply per token. GitHub publishes its own per-token quotas for authenticated REST requests on github.com. On a 429, TaskJuice surfaces a retryable rate-limit error and respects the backoff.
• A webhook signing secret is required for every trigger. Deliveries without a valid X-Hub-Signature-256 signature are rejected.
• github.com only. The connection targets api.github.com. There is no host or instance field, so GitHub Enterprise Server (self-managed) is not supported by this integration. If you manage GitLab projects on a self-managed host, see the GitLab integration.
• Triggers are real-time and single-event. Each webhook POST is one activation. There is no polling, batching, or digest mode.
• Issue, pull request, and release events are broad. A single trigger fires across many sub-actions. Filter on the action field downstream to scope to a specific lifecycle transition.