Baserow GitHub Integration - REST API and Webhooks

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 with write permissions.
• A Baserow automation configured to send HTTP POST requests through the database REST 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 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 for a similar pattern with another repository platform, and Vercel integration for connecting Baserow to a deployment pipeline.