Reference · built on requestConnectorWork & ticket management

GitHub

Issues, pull requests, labels, milestones, and Projects from GitHub repositories through GitHub's REST and GraphQL APIs and webhooks.

Request accessPricing ↗

About

GitHub hosts source code repositories for individuals and organizations. Each repository carries issues and pull requests with labels, assignees, milestones, comments, and timeline events, and GitHub's REST API treats every pull request as an issue. Projects sit at the organization or user level and are managed through the GraphQL API as ProjectV2 objects and items.

Through Fibric, an operator lists issues by state, label, or since, receives webhook events such as issues and issue_comment, and proposes a label, an assignee, a comment, or a state change. You approve each change before it is applied, and the connector keeps a record of what it did and how to reverse it.

This is a reference listing. It documents what Fibric would read from GitHub and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Issues through GET /repos/{owner}/{repo}/issues with state open, closed, or all, labels, assignee, since, sort, and per_page up to 100
  • Issue comments through GET /repos/{owner}/{repo}/issues/{issue_number}/comments with a since timestamp
  • Labels, milestones, assignees, sub-issues, issue dependencies, and timeline events for a repository
  • Projects, their items, and field values through the GraphQL API, as ProjectV2 and ProjectV2Item
  • Webhook events issues, issue_comment, pull_request, pull_request_review, label, milestone, projects_v2, and projects_v2_item
  • Issue event actions such as opened, edited, closed, reopened, assigned, labeled, milestoned, locked, and transferred

Proposed actions

  • Target capability: propose a title, body, state, state_reason, assignees, labels, milestone, or type change through PATCH /repos/{owner}/{repo}/issues/{issue_number}
  • Target capability: propose a comment through POST /repos/{owner}/{repo}/issues/{issue_number}/comments
  • Target capability: propose a new issue through POST /repos/{owner}/{repo}/issues
  • Target capability: propose locking an issue through PUT /repos/{owner}/{repo}/issues/{issue_number}/lock
  • Target capability: propose adding an item to a project through addProjectV2ItemById, then setting a field through updateProjectV2ItemFieldValue

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Triage new issues

    On the issues event with action opened, the operator reads the title and body and proposes labels and an assignee for your approval.

    With Ticket Triage

  • Chase a stale issue

    The operator lists open issues sorted by updated and proposes a comment asking for status, or a close with state_reason not_planned, on issues idle past a set age.

    With Action Follow-up

  • Link a support ticket to its issue

    When a ticket needs engineering, the operator proposes a new issue with the ticket summary and adds it to the team's project.

    With Escalation Packet

  • Watch the change freeze

    On pull_request events the operator checks the target branch and the window and proposes a comment on any merge attempt during a declared freeze.

    With Change Freeze

Requirements

  • A repository or organization where the app is installed, or a fine-grained personal access token scoped to it
  • The Issues repository permission: read for listing and getting issues, write for creating, updating, and commenting
  • The read:project scope for Projects queries and the project scope for mutations
  • A webhook on the repository or organization with a secret, so each delivery carries X-Hub-Signature-256
Authentication
A GitHub App installation access token, a GitHub App user access token, or a fine-grained personal access token; Issues endpoints need the Issues repository permission at read or write, and Projects need the read:project scope for queries or project for mutations.

Limits

  • The primary rate limit is 5,000 requests per hour for a user or an installation; installations on GitHub Enterprise Cloud organizations get 15,000
  • Secondary limits: no more than 100 concurrent requests, 900 points per minute per endpoint, and 80 content-creating requests per minute, 500 per hour
  • Projects have no REST API, and an item cannot be added and updated in one GraphQL call
  • Every pull request appears in issue lists; the connector filters pull requests out before proposing issue changes

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request GitHub ↗

Questions and answers

Which permission does the connector need for issues?
For GET /repos/{owner}/{repo}/issues and Get an issue, the fine-grained token needs the Issues repository permission at read. For Create an issue, Update an issue, and comments it needs Issues at write. GitHub App installation tokens, GitHub App user access tokens, and fine-grained personal access tokens all work.
How are Projects read and changed?
Through the GraphQL API only. A project is a ProjectV2 and each row a ProjectV2Item. addProjectV2ItemById adds an issue or pull request, updateProjectV2ItemFieldValue sets a field, and deleteProjectV2Item removes a row. Adding and updating cannot happen in the same call. Tokens need read:project for queries and project for mutations.
What happens at the rate limit?
Responses carry x-ratelimit-limit, x-ratelimit-remaining, and x-ratelimit-reset in UTC epoch seconds. The primary limit is 5,000 requests per hour per user or installation. Secondary limits return retry-after; the connector waits the stated seconds and stays under 100 concurrent requests and 80 content-creating requests per minute.
Ask about GitHub

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with GitHub through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy