Skip to the operations

Developer tools

GitHub in a decision flow.

44 GitHub operations a decision flow can call directly, with the credentials your own contract issued. The response is data the rest of the flow reads, branches on, and keeps in the trace.

Category
Developer tools
Type
Integration
Authentication
API key or OAuth 2.0
Test environment
Production host only

Who they are

Source control, pull requests, issues and Actions workflows in one API.

GitHub hosts Git repositories and the collaboration around them: pull requests, issues, reviews, releases and automated Actions workflows. Its REST API exposes those same resources and signs repository webhook deliveries, so a flow can both act on development work and start from an event in a repository.

What a flow can call

44 operations, each one a step you can place on the canvas.

  1. GET/user

    Get the authenticated user

    Verifies the credential and returns the GitHub user it acts as.

  2. GET/users/$data.github_username/repos?per_page=100

    List a user's repositories

    Returns the first 100 public repositories for a user.

  3. GET/user/repos?visibility=all&affiliation=owner,collaborator,organization_member&per_page=100

    List repositories visible to the token

    Returns the first 100 repositories the connected identity can see, including private repositories allowed by the token.

  4. GET/issues?filter=assigned&state=all&per_page=100

    List issues assigned to a user

    Returns the first 100 issues and pull requests assigned to the authenticated user across repositories.

  5. GET/orgs/$data.github_organization/repos?type=all&per_page=100

    List organization repositories

    Returns the first 100 organization repositories visible to the token.

  6. GET/orgs/$data.github_organization/members?per_page=100

    List organization members

    Returns the first 100 public organization members.

  7. GET/repos/$data.github_owner/$data.github_repository

    Get a repository

    Returns metadata, permissions, default branch, visibility, topics and counters for one repository.

  8. GET/repos/$data.github_owner/$data.github_repository/community/profile

    Get a repository's community profile

    Returns the health percentage and the detected README, license, code of conduct, contributing guide, issue templates and pull-request template.

  9. GET/repos/$data.github_owner/$data.github_repository/license

    Get a repository's license

    Returns the detected license and its Base64-encoded file contents.

  10. GET/repos/$data.github_owner/$data.github_repository/traffic/popular/paths

    List popular repository paths

    Returns up to ten popular content paths from the last 14 days.

  11. GET/repos/$data.github_owner/$data.github_repository/traffic/popular/referrers

    List repository referrers

    Returns up to ten referring domains from the last 14 days.

  12. GET/repos/$data.github_owner/$data.github_repository/contents/$data.github_path?ref=$data.github_ref

    Get a file or directory

    Returns a file (content is Base64 encoded) or a directory listing at a branch, tag or commit SHA.

  13. PUT/repos/$data.github_owner/$data.github_repository/contents/$data.github_path

    Create a file

    Set data.github_file_create to { message, content } plus optional branch, committer and author fields.

  14. PUT/repos/$data.github_owner/$data.github_repository/contents/$data.github_path

    Update a file

    Set data.github_file_update to { message, content, sha } plus optional branch, committer and author fields.

  15. DELETE/repos/$data.github_owner/$data.github_repository/contents/$data.github_path

    Delete a file

    Set data.github_file_delete to { message, sha } plus optional branch, committer and author fields.

  16. GET/repos/$data.github_owner/$data.github_repository/issues?state=all&per_page=100

    List repository issues

    Returns the first 100 issues and pull requests. GitHub represents pull requests as issues here; exclude rows with a pull_request property when you need issues only.

  17. GET/repos/$data.github_owner/$data.github_repository/issues/$data.github_issue_number

    Get an issue

    Returns one issue or pull request by its repository-scoped number.

  18. POST/repos/$data.github_owner/$data.github_repository/issues

    Create an issue

    Set data.github_issue_create to { title } plus optional body, assignees, milestone and labels fields.

  19. PATCH/repos/$data.github_owner/$data.github_repository/issues/$data.github_issue_number

    Update an issue

    Set data.github_issue_update to the fields to change: title, body, state, state_reason, milestone, labels or assignees.

  20. POST/repos/$data.github_owner/$data.github_repository/issues/$data.github_issue_number/comments

    Add a comment to an issue or pull request

    Adds a Markdown conversation comment to an issue or pull request.

  21. PUT/repos/$data.github_owner/$data.github_repository/issues/$data.github_issue_number/lock

    Lock an issue or pull request

    Locks the conversation. Set github_lock_reason to off-topic, too heated, resolved or spam.

  22. DELETE/repos/$data.github_owner/$data.github_repository/issues/$data.github_issue_number/lock

    Unlock an issue or pull request

    Unlocks the conversation. Success is 204 with an empty body.

  23. GET/repos/$data.github_owner/$data.github_repository/pulls?state=all&per_page=100

    List pull requests

    Returns the first 100 pull requests, newest first.

  24. GET/repos/$data.github_owner/$data.github_repository/pulls/$data.github_pull_number

    Get a pull request

    Returns one pull request, including mergeability metadata.

  25. POST/repos/$data.github_owner/$data.github_repository/pulls

    Create a pull request

    Set data.github_pull_create to { title, head, base } plus optional body and draft fields.

  26. PATCH/repos/$data.github_owner/$data.github_repository/pulls/$data.github_pull_number

    Update or close a pull request

    Set data.github_pull_update to any of title, body, state, base or maintainer_can_modify.

  27. PUT/repos/$data.github_owner/$data.github_repository/pulls/$data.github_pull_number/merge

    Merge a pull request

    Set data.github_pull_merge to any of commit_title, commit_message, sha and merge_method.

  28. GET/repos/$data.github_owner/$data.github_repository/pulls/$data.github_pull_number/reviews?per_page=100

    List pull-request reviews

    Returns the first 100 submitted and pending reviews for a pull request.

  29. GET/repos/$data.github_owner/$data.github_repository/pulls/$data.github_pull_number/reviews/$data.github_review_id

    Get a pull-request review

    Returns a single review by its numeric review id.

  30. POST/repos/$data.github_owner/$data.github_repository/pulls/$data.github_pull_number/reviews

    Create a pull-request review

    Set data.github_review_create to any of body, event, commit_id and comments.

  31. PUT/repos/$data.github_owner/$data.github_repository/pulls/$data.github_pull_number/reviews/$data.github_review_id

    Update a pending pull-request review

    Replaces the summary body of a pending review. GitHub rejects updates after the review has been submitted.

  32. GET/repos/$data.github_owner/$data.github_repository/releases?per_page=100

    List releases

    Returns the first 100 releases. The API excludes ordinary Git tags that have no GitHub release record.

  33. GET/repos/$data.github_owner/$data.github_repository/releases/$data.github_release_id

    Get a release

    Returns one release by numeric release id, not by tag.

  34. POST/repos/$data.github_owner/$data.github_repository/releases

    Create a release

    Set data.github_release_create to { tag_name } plus optional target_commitish, name, body, draft, prerelease and generate_release_notes fields.

  35. PATCH/repos/$data.github_owner/$data.github_repository/releases/$data.github_release_id

    Update a release

    Set data.github_release_update to only the release fields to change, such as tag_name, name, body, draft, prerelease or make_latest.

  36. DELETE/repos/$data.github_owner/$data.github_repository/releases/$data.github_release_id

    Delete a release

    Permanently deletes the GitHub release record. It does not delete the Git tag.

  37. GET/repos/$data.github_owner/$data.github_repository/actions/workflows?per_page=100

    List Actions workflows

    Returns the first 100 Actions workflows, including their ids, file paths and enabled states.

  38. GET/repos/$data.github_owner/$data.github_repository/actions/workflows/$data.github_workflow_id

    Get an Actions workflow

    Gets a workflow by numeric id or by workflow file name, such as ci.yml.

  39. GET/repos/$data.github_owner/$data.github_repository/actions/workflows/$data.github_workflow_id/runs?per_page=100

    List runs for an Actions workflow

    Returns the first 100 runs for a workflow. Add status, branch, actor, event or created filters to the node query when required.

  40. POST/repos/$data.github_owner/$data.github_repository/actions/workflows/$data.github_workflow_id/dispatches

    Dispatch an Actions workflow

    Set data.github_workflow_dispatch to { ref } plus an optional inputs object.

  41. PUT/repos/$data.github_owner/$data.github_repository/actions/workflows/$data.github_workflow_id/enable

    Enable an Actions workflow

    Enables a disabled workflow. Success is 204 with an empty body.

  42. PUT/repos/$data.github_owner/$data.github_repository/actions/workflows/$data.github_workflow_id/disable

    Disable an Actions workflow

    Disables a workflow. Success is 204 with an empty body; scheduled and event-based runs stop until it is enabled again.

  43. GET/repos/$data.github_owner/$data.github_repository/hooks?per_page=100

    List repository webhooks

    Returns the first 100 repository webhooks. Pair this with an ArboRule flow trigger when GitHub should start a decision.

  44. DELETE/repos/$data.github_owner/$data.github_repository/hooks/$data.github_hook_id

    Delete a repository webhook

    Permanently removes the repository webhook. Success is 204 with an empty body.

Where it sits in the decision

Developer tools calls have a natural place in a flow.

Repository automation belongs around the lifecycle of a policy rather than inside its business logic: open review work when evidence needs attention, dispatch a checked workflow when a version moves, or start a decision from a signed repository event. Keeping those calls in the trace records exactly which commit, issue or run the decision touched.

Whatever GitHub returns is part of the run, so it is part of the record. When someone asks months later why an applicant was declined, the answer cites what came back at the time rather than re-fetching from a service whose answer has since changed.

  • 01Add GitHub as a connection authenticating with an API key or OAuth 2.0.
  • 02GitHub has one host for both environments, so guard test runs with your own credentials and limits.
  • 03Place a Connection node and pick an operation — “Get the authenticated user” is usually the first one a flow needs.
  • 04Map the response into the fields your rules read, then test the whole path before it carries live traffic.

Common questions

Using GitHub in a flow.

How do I connect GitHub to a decision flow?

Add GitHub as a connection in your workspace authenticating with an API key or OAuth 2.0, with the credentials your own contract issued — ArboRule calls the provider as you, and never holds a contract on your behalf. Once the connection exists, any flow in the workspace can place a Connection node and choose one of its operations. The credentials live on the connection, not in the flow, so a policy owner can use GitHub in a decision without ever seeing the secret.

Can I test GitHub without touching production?

GitHub exposes one host for both environments, so there is no separate sandbox to point at. Test runs still execute in Sandbox and are recorded separately in decision history, but the call goes to the same place as production — so guard it with your own test credentials, rate limits, or data.

What can a flow call on GitHub?

44 operations, including “Get the authenticated user”, “List a user's repositories”, “List repositories visible to the token”. Each one is a step you place on the canvas and map into the fields your rules read, and most flows start with “Get the authenticated user”. The list comes from the same manifest the engine uses to make the call, so this page cannot describe an operation the product does not have.

Where in a decision should GitHub be called?

Repository automation belongs around the lifecycle of a policy rather than inside its business logic: open review work when evidence needs attention, dispatch a checked workflow when a version moves, or start a decision from a signed repository event. Keeping those calls in the trace records exactly which commit, issue or run the decision touched.

Ready when you are

Wire GitHub into a real decision.

Build the flow in Sandbox, connect your account, and watch the decision pull what it needs before it answers.

Read the docs