GitHub

BirchSeek writes an MDX file with frontmatter matched to your content collection schema, pushes it to its own branch, and opens a pull request. Your preview deploys run against it; it goes live when you merge. There is no access token to create, paste or rotate: BirchSeek authenticates as a GitHub App you install.

What BirchSeek does

• Creates a branch named birchseek/{slug} from your base branch - never commits to main
• Writes one MDX file at your configured path, e.g. src/content/blog/{slug}.mdx
• Maps title, description, publish and update dates, tags, and FAQ pairs to your frontmatter keys (Astro content collections preset built in)
• Opens a pull request titled "Add article: <article title>" and returns its URL for review
• Mints a fresh one-hour installation token for each publish, so the connector stores no credential of its own
• Checks repository push access and pull-request reads before the connection is marked ready

Setup

1. 01

   Install the BirchSeek GitHub App

   In onboarding, or later under Connectors → GitHub, press Connect GitHub. That sends you to GitHub's own install screen, where you choose the account that owns your blog - your personal account or an organization - and which repositories the app may touch. Choose Only select repositories and pick your content repo. GitHub asks you to approve two repository permissions: Contents (read and write) to commit the article file, and Pull requests (read and write) to open the PR. Metadata (read) is added automatically. On an organization you do not own, GitHub records the install as a request instead and an owner has to approve it; BirchSeek shows it as pending until they do.

   On screen: GitHub's install screen for BirchSeek with 'Only select repositories' chosen, your content repo picked, and the permission list showing Contents: Read and write, Pull requests: Read and write, Metadata: Read.

2. 02

   Finish the connection while signed in

   GitHub returns you to BirchSeek's callback, which parks the installation rather than binding it. It becomes yours only when your own signed-in browser claims it a moment later - the step that stops somebody else's install link attaching their repository access to your account, or yours to theirs. You then pick the installation and the repository from the ones GitHub says it granted, and set the base branch, the content directory and the frontmatter preset. Astro content collections is built in; a custom key mapping covers the rest.

   On screen: The connector form with a GitHub account picker, a repository list populated from the installation, a base branch, a path template like src/content/blog/{slug}.mdx, and a frontmatter mapping table.

3. 03

   Check access

   BirchSeek reads the repository and lists its open pull requests, confirming push access and pull-request reads. The check does not create a branch, file, or pull request; GitHub exposes no read-only way to prove pull-request write, so the first publish is the definitive test of that one.

   On screen: A successful result naming the repository and its default branch, with push access confirmed.

Nothing to store and nothing to revoke: the connector holds no secret, and access ends the moment you uninstall the app or drop the repository from the installation in your GitHub settings. BirchSeek learns of it by webhook, and reconciles every six hours either way, then marks the connector failing and emails you.

GitHub reference↗