GitHub Connector

SourceAPI DocsAPI ChangelogConnector Changelog

Description

GitHub is a development platform that provides Git repository hosting, code collaboration, and project management tools. This component allows managing repositories, issues, pull requests, workflows, and users within a GitHub organization.

API Documentation

This component was built using the GitHub REST API Documentation currently utilizing version 2022-11-28.

The GitHub REST API is extensive, with almost a thousand unique endpoints. This component has actions that wrap some of those endpoints that are commonly used in integrations. Additional GitHub endpoints can be wrapped in actions as integration needs require. Alternatively, the Raw Request action can interact with any GitHub endpoint.

Connections

OAuth 2.0

key: oauth2

To connect to GitHub, create a new OAuth 2.0 application.

Prerequisites

• A GitHub account with permission to create OAuth Apps for the user or organization that owns the repositories
• Access to the repositories or organizations the integration will work with

Setup Steps

1. Navigate to GitHub Developer Settings to create a new OAuth App.
2. Fill in the required fields:
   • Application name: A descriptive name for the application
   • Homepage URL: The organization or application website
   • Authorization callback URL: https://oauth2.prismatic.io/callback
3. Click Register application.
4. Click Generate a new client secret to create a client secret.
5. Copy the Client ID and Client Secret values.

Configure the Connection

• Enter the Client ID and Client Secret from the OAuth App.
• Determine what scopes the use case requires and add those to Scopes, separating each with a space.
  • Common scopes include: repo, user, admin:org, workflow
  • For full repository access and workflow permissions, use: repo user admin:org workflow

The connection is now ready to authenticate with GitHub.

Input	Notes	Example
Authorize URL	The OAuth 2.0 Authorization URL for GitHub.	https://github.com/login/oauth/authorize
Client ID	The Client ID from your GitHub OAuth App. Find this in GitHub Settings > Developer settings > OAuth Apps.	Iv1.a629723000000000
Client Secret	The Client Secret from your GitHub OAuth App. Keep this value secure.
Scopes	Space-separated list of OAuth scopes. See GitHub's documentation for available scopes.	repo user admin:org
Token URL	The OAuth 2.0 Token URL for GitHub.	https://github.com/login/oauth/access_token

Triggers

Event Webhook

Receive event notifications from GitHub. Automatically creates and manages a webhook subscription for the selected event types when the instance is deployed, and removes the subscription when the instance is deleted. | key: eventWebhook

Input	Notes	Example
Connection
Events	The list of event types that will trigger the webhook.
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World

The Event Webhook trigger automatically creates and manages GitHub webhooks for a specified repository. This trigger handles the complete webhook lifecycle, including creation during instance deployment and deletion when the instance is removed.

How It Works

When an integration instance is deployed:

1. The trigger automatically creates a webhook in the specified GitHub repository using the GitHub REST API
2. A random 256-bit secret is generated and securely stored in the integration's cross-flow state
3. The webhook is configured to send events to the flow-specific webhook URL
4. The webhook is configured with the selected event types

When the integration instance is deleted:

1. The trigger automatically removes the webhook from the GitHub repository
2. The stored webhook ID and secret are cleaned up from cross-flow state

When an instance is redeployed, the trigger compares the current Owner, Repository Name, and Events against the values stored when the webhook was created. If all three match, the existing webhook is left in place. If any of them differ, the existing GitHub webhook is deleted and a replacement is created for the current configuration, which also issues a new signing secret. The Events comparison ignores ordering, so selecting the same event types in a different order is not treated as a change.

This automatic lifecycle management eliminates the need to manually configure webhooks in GitHub's repository settings.

Webhook Signature Verification

The trigger automatically generates a random secret during webhook creation and uses it to validate HMAC-SHA256 signatures on all incoming webhook requests.

For more information about GitHub's signature mechanism, see GitHub's webhook security documentation.

Required GitHub Permissions

The connection must have the following permissions:

• Repository webhooks: Read and write access to manage repository webhooks
• Repository contents: Read access (for most webhook event types)

For organization owned repositories, the authenticated user or GitHub App must have admin access to the repository.

Event Types

The Events input offers a fixed list of 51 GitHub webhook event types, and the webhook is registered for the selected ones. For the payload structure of each event, see the GitHub webhook events and payloads documentation.

Available Events (51)

Event	Description
commit_comment	Activity on a commit comment.
create	A Git branch or tag is created.
delete	A Git branch or tag is deleted.
deploy_key	Activity on a deploy key.
deployment	Activity on a deployment.
deployment_status	Activity on a deployment status.
discussion	Activity on a discussion.
discussion_comment	Activity on a comment in a discussion.
fork	Someone forks the repository.
github_app_authorization	A user revokes their authorization of a GitHub App.
gollum	Someone creates or updates a wiki page.
installation	Activity on a GitHub App installation.
installation_repositories	A change to which repositories a GitHub App installation can access.
issue_comment	Activity on a comment on an issue or pull request.
issues	Activity on an issue.
label	Activity on a label.
marketplace_purchase	Activity on a GitHub Marketplace purchase.
member	Activity on a repository collaborator.
membership	Activity on team membership.
meta	Activity on the webhook itself, such as its deletion.
milestone	Activity on a milestone.
organization	Activity on an organization and its members.
org_block	An organization owner or moderator blocks or unblocks a non-member.
package	Activity on a GitHub Packages package.
page_build	An attempted build of a GitHub Pages site, whether or not it succeeds.
ping	Sent once when the webhook is created.
project	Activity on a project (classic).
project_card	Activity on a card in a project (classic).
project_column	Activity on a column in a project (classic).
projects_v2_item	Activity on an item in an organization-level project.
public	Repository visibility changes from private to public.
pull_request	Activity on a pull request.
pull_request_review	Activity on a pull request review.
pull_request_review_comment	Activity on a comment in a pull request review.
pull_request_review_thread	Activity on a comment thread in a pull request.
push	A push to a repository branch.
release	Activity on a release.
repository_dispatch	A GitHub App sends a POST request to the repository's dispatches endpoint.
repository	Activity on the repository itself.
repository_import	A repository is imported to GitHub.
repository_vulnerability_alert	Activity on a repository security vulnerability alert. GitHub is closing this event down.
security_advisory	Activity on a global security advisory reviewed by GitHub.
sponsorship	Activity on a sponsorship listing.
star	Activity on repository stars.
status	The status of a Git commit changes.
team	Activity on a team in an organization.
team_add	A team is added to the repository.
watch	Activity on watching, or subscribing to, the repository.
workflow_dispatch	A GitHub Actions workflow is manually triggered.
workflow_job	Activity on a job in a GitHub Actions workflow run.
workflow_run	Activity on a run of a GitHub Actions workflow.

Returned Data

The trigger returns the complete webhook payload received from GitHub. The structure of the payload depends on the event type that triggered the webhook. Each event type has a specific payload format documented in GitHub's webhook events reference.

Example payload structure for a pull_request event:

Example Event Payload

{
  "action": "opened",
  "number": 42,
  "pull_request": {
    "id": 123456789,
    "number": 42,
    "state": "open",
    "title": "Update documentation",
    "user": {
      "login": "octocat",
      "id": 1
    },
    "body": "This PR updates the documentation with examples",
    "created_at": "2023-05-15T14:30:00Z",
    "head": {
      "ref": "feature-branch",
      "sha": "abc123..."
    },
    "base": {
      "ref": "main",
      "sha": "def456..."
    }
  },
  "repository": {
    "id": 123456,
    "name": "example-repo",
    "full_name": "octocat/example-repo",
    "owner": {
      "login": "octocat",
      "id": 1
    }
  },
  "sender": {
    "login": "octocat",
    "id": 1
  }
}

Example payload structure for an issues event:

Example issues Event Payload

{
  "action": "opened",
  "issue": {
    "id": 987654321,
    "number": 142,
    "state": "open",
    "title": "Add dark mode toggle",
    "user": {
      "login": "octocat",
      "id": 1
    },
    "body": "The settings page should offer a dark mode toggle",
    "labels": [
      {
        "id": 208045946,
        "name": "enhancement"
      }
    ],
    "created_at": "2023-05-15T14:30:00Z",
    "updated_at": "2023-05-15T14:30:00Z"
  },
  "repository": {
    "id": 123456,
    "name": "example-repo",
    "full_name": "octocat/example-repo",
    "owner": {
      "login": "octocat",
      "id": 1
    }
  },
  "sender": {
    "login": "octocat",
    "id": 1
  }
}

Example Payload for Event Webhook⤓

Loading…

---

New and Updated Records

Retrieves existing and ongoing issues (including pull requests) for a specified GitHub repository. Load history once, check for changes on a schedule, or both. | key: pollChangesTrigger

Input	Notes	Example
Connection
Look-back Date	The date the initial sync starts from, in YYYY-MM-DD format. Cannot be a future date. Leave empty to start from the first recurrence with no backfill. When set, the initial sync seeds each record modified on or after this date once, ignoring the visibility filters.	2026-01-01
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Show New Records	When true, issues created after the last poll are emitted on the created branch.	true
Show Updated Records	When true, issues updated since the last poll but created earlier are emitted on the updated branch.	true

The New and Updated Records trigger polls a GitHub repository for issues and pull requests that have changed since the last poll. GitHub's issues endpoint returns both issues and pull requests, so both are included.

The trigger checks for:

• Created: Records whose created_at falls after the last poll.
• Updated: Records modified since the last poll but created earlier.

How It Works

1. The trigger runs on the configured schedule.
2. It queries the repository's issues endpoint using GitHub's since parameter, requesting records whose updated_at is at or after its stored position, oldest first. The position is kept to the second, which is the precision GitHub reports.
3. Because since is inclusive (greater than or equal to), a record updated in the same second as the position can be returned again. The trigger remembers which records it delivered in that second and does not emit them twice; downstream flows should still treat delivery as at-least-once.
4. Closed issues and pull requests are included (state=all) so changes to closed records are not missed.
5. Each returned record is partitioned by comparing its created_at to the stored position. Records created at or after it are emitted on the created branch; records that existed before it but were modified are emitted on the updated branch.
6. The trigger stores the updated_at of the newest record it received as its new position, so the next recurrence resumes from exactly there. A recurrence that receives nothing leaves the position unchanged.

The created and updated branches can be enabled or disabled independently using the Show New Records and Show Updated Records inputs.

Initial Sync

An initial sync seeds a complete starting state rather than a change feed, so inputs that narrow which changes are reported would leave gaps in it: Show New Records and Show Updated Records are ignored while it runs, and are the only inputs it ignores. It begins on the first recurrence, when the trigger has no stored position and a Look-back Date (YYYY-MM-DD) is set, and seeds every record modified on or after that date exactly once. Left empty, there is no sync and the trigger starts from its first recurrence.

The window has no fixed upper bound, so a record modified mid-drain is swept into the sync rather than deferred to the schedule. Each recurrence advances the position to the newest record it actually received, never to the wall clock, and the first incremental recurrence resumes from exactly there; nothing in the payload marks the handoff. With batching off the drain is uncapped and finishes in one recurrence; with batching on each recurrence returns at most 500 records, oldest first, so a larger window spans several recurrences before the toggles apply again. The one exception is a group of 500 or more records modified in the same second, which is delivered whole in one recurrence because GitHub offers no way to page within a second.

Owner and Repository Name still apply throughout. The trigger has no page-size or field-selection input, so nothing else is suppressed.

Batching

Batching is enabled per flow on this trigger: each changed record is dispatched as its own execution, or grouped by the configured batch size. Batch size and batch concurrency can both be overridden per instance. Raising concurrency increases the request volume sent to GitHub.

To turn it on, select the flow's trigger, open the Flow control tab, and switch on Enable Batching. Under Batch Size, keep Trigger default or choose Custom batch size. Batch Concurrency is optional; leave it blank for no batch-level limit.

With batching off, a downstream step reads body.data.created and body.data.updated, each an array of records. With batching on those two fields do not exist. Each execution receives one { "changeType": ..., "record": ... } item instead, or an array of those items when the batch size is greater than 1. Every step that reads body.data.created or body.data.updated must be updated before batching is enabled, or it breaks the moment the switch is flipped. Because batching is enabled per flow, the change is scoped to that flow rather than to the component or to other flows using the same trigger.

Returned Data

With batching off, the trigger returns an object under body.data with two arrays, created and updated, each containing GitHub issue records. Records that represent pull requests include a pull_request property.

Example Response

{
  "data": {
    "created": [
      {
        "id": 2147483647,
        "number": 142,
        "title": "Add dark mode toggle",
        "state": "open",
        "html_url": "https://github.com/octocat/Hello-World/issues/142",
        "created_at": "2026-05-26T14:30:00Z",
        "updated_at": "2026-05-26T14:30:00Z"
      }
    ],
    "updated": [
      {
        "id": 2147480000,
        "number": 87,
        "title": "Fix pagination off-by-one",
        "state": "closed",
        "html_url": "https://github.com/octocat/Hello-World/pull/87",
        "created_at": "2026-04-12T09:00:00Z",
        "updated_at": "2026-05-26T15:45:00Z",
        "pull_request": {
          "url": "https://api.github.com/repos/octocat/Hello-World/pulls/87",
          "merged_at": "2026-05-26T15:45:00Z"
        }
      }
    ]
  }
}

With batching on, each execution receives one record tagged with how it changed, or an array of such items when the batch size is greater than 1. The created and updated arrays are not part of this shape.

Fields shown are representative. The full response object includes additional properties.

Batched Item

{
  "changeType": "created",
  "record": {
    "id": 2147483647,
    "number": 142,
    "title": "Add dark mode toggle",
    "state": "open",
    "html_url": "https://github.com/octocat/Hello-World/issues/142",
    "created_at": "2026-05-26T14:30:00Z",
    "updated_at": "2026-05-26T14:30:00Z"
  }
}

Example Payload for New and Updated Records⤓

Loading…

---

Webhook

Receive and validate webhook requests from GitHub for webhooks you configure. | key: webhook

Input	Notes	Example
Webhook Secret	An optional secret used to verify webhook authenticity. See GitHub's documentation for details.

The Webhook trigger receives and validates webhook requests from GitHub for manually configured webhook subscriptions. When a Webhook Secret is set, each request's X-Hub-Signature-256 header is checked against an HMAC-SHA256 of the raw request body before the flow runs.

How It Works

When a webhook request is received, the trigger:

1. Reads the X-Hub-Signature-256 header from the request
2. Computes an HMAC-SHA256 of the raw request body using the configured Webhook Secret
3. Rejects the request when the header is missing or the two values differ
4. Passes the request to the flow when they match

When Webhook Secret is left empty, no verification is performed and every request is accepted.

Compute the signature

const crypto = require("node:crypto");

const signature = `sha256=${crypto
  .createHmac("sha256", webhookSecret) // the same secret entered in GitHub
  .update(rawRequestBody) // the raw body, before JSON parsing
  .digest("hex")}`; // GitHub sends the hex digest, prefixed with sha256=

See GitHub's guide to validating webhook deliveries for the signature scheme.

Setting Up the Webhook in GitHub

1. Open the repository or organization Settings, then Webhooks, and click Add webhook
2. Set Payload URL to the flow's webhook URL
3. Set Content type to application/json
4. Enter a Secret, and enter the same value in this trigger's Webhook Secret input
5. Choose the events to deliver and save

GitHub's creating webhooks guide covers each field.

Event Types

The events delivered are chosen in GitHub when the webhook is created. The full catalog, with a payload example for each, is in GitHub's webhook events and payloads reference. Common choices are push, pull_request, issues, issue_comment, and release.

Returned Data

The trigger returns the request as GitHub sent it. The example below is an issues event with the opened action.

Example Payload

{
  "action": "opened",
  "issue": {
    "id": 1,
    "number": 1347,
    "title": "Found a bug",
    "state": "open",
    "html_url": "https://github.com/octocat/Hello-World/issues/1347",
    "user": { "login": "octocat", "id": 1 },
    "created_at": "2026-05-26T14:30:00Z",
    "updated_at": "2026-05-26T14:30:00Z"
  },
  "repository": {
    "id": 1296269,
    "name": "Hello-World",
    "full_name": "octocat/Hello-World"
  },
  "sender": { "login": "octocat", "id": 1 }
}

Fields shown are representative. The full response object includes additional properties.

Example Payload for Webhook⤓

Loading…

---

Data Sources

List Repos

List all of the authenticated user's repositories. | key: listReposForAuthenticatedUser | type: picklist

Input	Notes	Example
Connection

Example Payload for List Repos⤓

Loading…

---

Select Issue

Select an issue from the given owner/repo pair. | key: selectIssueForAuthenticatedUser | type: picklist

Input	Notes	Example
Assignee	The user that is assigned to the issue, use 'none' for issues with no assignee, or '*' for issues assigned to any user
Connection
Direction	The direction to sort the results by	asc
Labels	A list of comma separated label names
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Since	Only show notifications updated after the given time
Sort	What to sort results by	created
State	Indicates the state of the issues to return	open

---

Select Organization

Select an organization from a list of organizations for the authenticated user. | key: selectOrganizationsForAuthenticatedUser | type: picklist

Input	Notes	Example
Connection

---

Select Pull Request from Repo

Select a pull request from a list of pull requests given the provided owner/repo pair. | key: selectPullRequestFromRepo | type: picklist

Input	Notes	Example
Base	Filter pulls by base branch name
Connection
Direction	The direction to sort the results by	asc
Head	Filter pulls by head user or head organization and branch name in the format of 'user:ref-name' or 'organization:ref-name'
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Sort	What to sort results by	created
State	Indicates the state of the pull requests to return	open

---

Select User from Organization

Select a user from a list of GitHub users in an organization. | key: selectUserFromOrganization | type: picklist

Input	Notes	Example
Connection
Organization	The name of the organization	octocat

---

Actions

Actions Create Workflow Dispatch

Create a workflow dispatch event | key: actionsCreateWorkflowDispatch

Input	Notes	Example
Connection
Inputs	Input keys and values configured in the workflow file. This can be a JSON input mapping, or a reference to a previous step that returned an object.	{"input1":"My Value","input2":"My Other Value"}
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Ref	The git reference for the workflow
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Workflow Id	The ID of the workflow

Example Payload for Actions Create Workflow Dispatch⤓

Loading…

---

Git Create Blob

Create a blob | key: gitCreateBlob

Input	Notes	Example
Connection
Content	The content of the new blob
Encoding	The encoding used for "content"	utf-8
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World

Example Payload for Git Create Blob⤓

Loading…

---

Git Create Ref

Create a reference | key: gitCreateRef

Input	Notes	Example
Connection
Key		"refs/heads/newbranch"
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Ref	The name of the fully qualified reference (ie: "refs/heads/master")
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Sha	The SHA1 value for this reference

Example Payload for Git Create Ref⤓

Loading…

---

Git Create Tree

Create a tree | key: gitCreateTree

Input	Notes	Example
Base Tree	The SHA1 of an existing Git tree object which will be used as the base for the new tree	9fb037999f264ba9a7fc6274d15fa3ae2ab98312
Connection
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Tree	Objects (of "path", "mode", "type", and "content" or "sha") specifying a tree structure. See https://docs.github.com/en/rest/git/trees#create-a-tree	[ { "path": "test.txt", "mode": "100644", "content": "This is a test" } ]

Example Payload for Git Create Tree⤓

Loading…

---

Git Get Ref

Get a reference | key: gitGetRef

Input	Notes	Example
Connection
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Ref	ref parameter
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World

Example Payload for Git Get Ref⤓

Loading…

---

Issues Create Comment

Create an issue comment | key: issuesCreateComment

Input	Notes	Example
Body	The contents of the comment
Connection
Issue Number	The number that identifies the issue
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World

Example Payload for Issues Create Comment⤓

Loading…

---

Issues List Comments

List issue comments | key: issuesListComments

Input	Notes	Example
Connection
Issue Number	The number that identifies the issue
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Pagination	Page number and results-per-page controls.
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Since	Only show notifications updated after the given time

Example Payload for Issues List Comments⤓

Loading…

---

Issues List For Repo

List repository issues | key: issuesListForRepo

Input	Notes	Example
Assignee	The user that is assigned to the issue, use 'none' for issues with no assignee, or '*' for issues assigned to any user
Connection
Creator	The user that created the issue
Direction	The direction to sort the results by	asc
Fetch All	When true, automatically fetches all pages of results.	false
Labels	A list of comma separated label names
Mentioned	A user that is mentioned in the issue.
Milestone	If an "integer" is passed, it should refer to a milestone by its "number" field
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Pagination	Page number and results-per-page controls.
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Since	Only show notifications updated after the given time
Sort	What to sort results by	created
State	Indicates the state of the issues to return	open

Example Payload for Issues List For Repo⤓

Loading…

---

Orgs List For Authenticated User

List organizations for the authenticated user | key: orgsListForAuthenticatedUser

Input	Notes	Example
Connection
Pagination	Page number and results-per-page controls.

Example Payload for Orgs List For Authenticated User⤓

Loading…

---

Pulls Create

Create a pull request | key: pullsCreate

Input	Notes	Example
Base	The name of the branch the changes are pulled into. This should be an existing branch in the repository.	main
Body	The contents/description of the pull request. Supports markdown formatting.	This PR fixes the authentication bug by updating the token validation logic. Fixes #123
Connection
Draft	When true, creates the pull request as a draft. Draft pull requests cannot be merged until marked as ready for review.	false
Head	The name of the branch where the changes are implemented. For cross-repository pull requests, use the format 'username:branch'.	feature-branch
Issue Number	The number that identifies the issue
Maintainer Can Modify	When true, maintainers can modify the pull request. See GitHub's documentation for details.	false
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Title	The title of the pull request. Required unless using the issue parameter.	Fix bug in authentication flow

Example Payload for Pulls Create⤓

Loading…

---

Pulls List

List pull requests | key: pullsList

Input	Notes	Example
Base	Filter pull requests by base branch name.	main
Connection
Direction	The direction to sort results (ascending or descending).
Head	Filter pull requests by head user or organization and branch name in the format "user:ref-name" or "organization:ref-name".	octocat:new-feature
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Pagination	Page number and results-per-page controls.
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Sort	The field to sort results by.	created
State	Filters pull requests by their state (open, closed, or all).	open

Example Payload for Pulls List⤓

Loading…

---

Raw Request

Send raw HTTP request to GitHub. | key: rawRequest

Input	Notes	Example
Connection
Data	The HTTP body payload to send to the URL.	{"exampleKey": "Example Data"}
File Data	File Data to be sent as a multipart form upload.	[{key: "example.txt", value: "My File Contents"}]
File Data File Names	File names to apply to the file data inputs. Keys must match the file data keys above.
Form Data	The Form Data to be sent as a multipart form upload.	[{"key": "Example Key", "value": new Buffer("Hello World")}]
Header	A list of headers to send with the request.	User-Agent: curl/7.64.1
Max Retry Count	The maximum number of retries to attempt. Specify 0 for no retries.	0
Method	The HTTP method to use.
Query Parameter	A list of query parameters to send with the request. This is the portion at the end of the URL similar to ?key1=value1&key2=value2.
Response Type	The type of data you expect in the response. You can request json, text, or binary data.	json
Retry On All Errors	If true, retries on all erroneous responses regardless of type. This is helpful when retrying after HTTP 429 or other 3xx or 4xx errors. Otherwise, only retries on HTTP 5xx and network errors.	false
Retry Delay (ms)	The delay in milliseconds between retries. This is used when 'Use Exponential Backoff' is disabled.	0
Timeout	The maximum time that a client will await a response to its request	2000
URL	Input the path only (/octocat), The base URL is already included (https://api.github.com). For example, to connect to https://api.github.com/octocat, only /octocat is entered in this field.	/octocat
Use Exponential Backoff	Specifies whether to use a pre-defined exponential backoff strategy for retries. When enabled, 'Retry Delay (ms)' is ignored.	false

The Raw Request action allows interacting with any GitHub REST API endpoint.

Suppose, for example, a call to GitHub's Render a Markdown document endpoint is needed. Enter /markdown as the URL and select POST as the Method. The HTTP request's body for that endpoint needs an object with text and mode, which can be a reference of a previous step. A previous code step, for example could look like this:

module.exports = async ({ logger, configVars }, stepResults) => {
  const text = `> #### The quarterly results look great!
>
> - Revenue was off the chart.
> - Profits were higher than ever.
>
>  *Everything* is going according to **plan**.`;
  const mode = "markdown";
  return { data: { text, mode } };
};

Example Payload for Raw Request⤓

Loading…

---

Repos Create Webhook

Create a repository webhook | key: reposCreateWebhook

Input	Notes	Example
Callback URL	The URL where webhook events will be sent.	https://your-webhook-endpoint.com/webhook/abc123
Connection
Events	The list of event types that will trigger the webhook.
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Webhook Secret	An optional secret used to verify webhook authenticity. See GitHub's documentation for details.

Example Payload for Repos Create Webhook⤓

Loading…

---

Repos Delete Instance Webhooks

Delete all webhooks pointed at this instance | key: reposDeleteInstanceWebhooks

Input	Notes	Example
Connection
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World

Example Payload for Repos Delete Instance Webhooks⤓

Loading…

---

Repos Delete Webhook

Delete a repository webhook by ID | key: reposDeleteWebhook

Input	Notes	Example
Connection
Hook ID	The unique identifier of the webhook.	12345678
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World

Example Payload for Repos Delete Webhook⤓

Loading…

---

Repos List For Org

List organization repositories | key: reposListForOrg

Input	Notes	Example
Connection
Direction	The order to sort by
Org	The organization name
Pagination	Page number and results-per-page controls.
Sort	The property to sort the results by	created
Type	Specifies the types of repositories to return

Example Payload for Repos List For Org⤓

Loading…

---

Repos List Webhooks

List webhooks of a repository | key: reposListWebhooks

Input	Notes	Example
Connection
Owner	The account owner of the repository. For example, in https://github.com/octocat/Hello-World, the owner is 'octocat'.	octocat
Repository Name	The name of the repository. For example, in https://github.com/octocat/Hello-World, the repository name is 'Hello-World'.	Hello-World
Show Only Instance Webhooks	When true, shows only webhooks that point to this instance.	true

Example Payload for Repos List Webhooks⤓

Loading…

---

Users Get Authenticated

Get the authenticated user | key: usersGetAuthenticated

Input	Notes	Example
Connection

Example Payload for Users Get Authenticated⤓

Loading…

---

Users Get By Username

Get a user | key: usersGetByUsername

Input	Notes	Example
Connection
Username	The GitHub username.	octocat

Example Payload for Users Get By Username⤓

Loading…

---

Changelog

2026-09-29

• Added opt-in batching to the New and Updated Records trigger, dispatching each changed record individually or in configured batches, with each recurrence returning at most 500 records (oldest first) so large backlogs drain over later recurrences; enabling it changes the shape a downstream step receives
• Added an optional Look-back Date input to the New and Updated Records trigger for performing an initial sync of records. The initial sync begins on the first recurrence and backfills every record modified on or after the specified date, seeding each once and ignoring the visibility filters. Leave it empty to start from the first recurrence with no backfill
• Added output schemas to 15 actions for improved field mapping during configuration
• Added inline action calling support to 18 actions for improved example output during configuration
• Updated the Repos List For Org, Orgs List For Authenticated User, Issues List For Repo, Issues List Comments, and Pulls List actions to group their page and per-page inputs into Pagination for an improved user experience; Fetch All stays a top-level toggle on Issues List For Repo
• Added documentation for the Webhook trigger and prerequisites for the OAuth 2.0 connection
• Fixed the New and Updated Records trigger so a record created during the same second the previous recurrence ran is delivered as a new record instead of being classed as updated, which dropped it when Show Updated Records was off
• Fixed the Event Webhook trigger so redeploying an instance no longer leaves an extra GitHub webhook registered on the repository, which previously caused each event to be delivered once per deployment; changing Owner, Repository Name, or Events now deletes the existing webhook before creating its replacement
• Fixed the Issues List For Repo action so the Per Page input is sent to GitHub as the API page-size parameter and Fetch All advances through pages instead of repeatedly fetching the first page

2026-06-02

Added New and Updated Records polling trigger that monitors a repository's issues and pull requests, routing newly created records to the created branch and modified records to the updated branch

2026-04-30

Updated spectral version

2026-04-07

Added global debug support across all actions for improved troubleshooting

2026-01-21

Added Event Webhook trigger that automatically creates and manages GitHub webhooks using lifecycle handlers

2025-11-19

Enhanced webhook triggers to support simulated test executions

2025-11-05

• Added inline data sources for organizations, issues, pull requests, and users to enhance data selection capabilities
• Added pagination support with sortBy functionality for improved data handling
• Enhanced List Pull Requests action with repository-specific filtering