# Baserow GitHub Integration - REST API and Webhooks

> A repository dispatch pattern triggers GitHub Actions from Baserow automations, while webhooks update rows on commits and merges - tokens and setup covered.

Source: https://opennix.org/en/docs/baserow/integrations/github-integration/


The open-source edition of Baserow connects to GitHub in both directions with no paid gateway in between: a repository dispatch pattern lets Baserow automations trigger GitHub Actions workflows, while GitHub webhooks update Baserow rows on commits, merged pull requests, and closed issues - this guide covers the common use cases, the dispatch architecture, and how to set up both directions.

## Overview

Development happens in GitHub: commits, pull requests, branches. Business context - roadmaps, priorities, approvals - is easier to manage in Baserow. The integration bridges the two: a repository dispatch pattern sends signals from Baserow to GitHub, and GitHub webhooks update Baserow records in response to repository events.

## Use Cases

- **Roadmap sync**: GitHub issues are mirrored into feature records in a Baserow table.
- **Bug triage**: bugs logged in Baserow land in the developer backlog as GitHub issues.
- **Release logs**: a changelog is generated in Baserow automatically when a release publishes.
- **Member onboarding**: a GitHub organization invite is created from a Baserow record.
- **Environment provisioning**: infrastructure is spun up once a Baserow record is approved.

## Architecture: the Repository Dispatch Pattern

The integration runs on a four-step loop:

1. **Signal** - a Baserow automation sends a dispatch event with payload metadata (row ID, action type).
2. **Reception** - GitHub receives and authenticates the request.
3. **Execution** - a GitHub Actions workflow performs the actual task.
4. **Feedback** - the result updates the originating Baserow row.

## Technical Requirements

- A GitHub Personal Access Token with `repo` scope.
- A Baserow [database (API) token](/docs/baserow/webhook-api/personal-api-tokens/) with write permissions.
- A Baserow automation configured to send HTTP POST requests through the [database REST API](/docs/baserow/webhook-api/database-api/).
- A GitHub Actions workflow file (`.github/workflows/baserow_handler.yml`) that accepts the dispatch event and runs the task.

## The Other Direction: GitHub Webhooks

GitHub webhooks cover the reverse scenario: Baserow listens passively for repository events and updates rows when developers commit code, merge a pull request, or close an issue. Setup goes through the same [Baserow webhooks](/docs/baserow/webhook-api/webhooks/) mechanism used across other integrations - a good fit for status-driven scenarios rather than action-driven ones.

## Anchoring Records by ID

Keep a cross-reference between the two systems: store the Baserow row ID in the GitHub issue, and the GitHub issue number in a Baserow field. This keeps record matching accurate at scale and prevents the same task from getting duplicated across both systems.

## Frequently Asked Questions

**Does the token need repository admin rights?** No - a GitHub Personal Access Token with `repo` scope is enough to read and write issues, pull requests, and trigger workflows; broader permissions aren't required for the scenarios above.

**Can webhooks alone cover this without the dispatch pattern?** Yes, if the only requirement is receiving events from GitHub into Baserow. The dispatch pattern is needed for the reverse direction - when Baserow needs to initiate an action in GitHub.

**What happens if the GitHub Actions workflow fails?** The Baserow row won't get its feedback update until the automation or script sends the request again - build retry logic into the workflow itself to handle this.

Related reading: [GitLab integration](/docs/baserow/integrations/gitlab-integration/) for a similar pattern with another repository platform, and [Vercel integration](/docs/baserow/integrations/vercel-integration/) for connecting Baserow to a deployment pipeline.