Release announcements

Ship a release, and ReachPill turns the release notes into on-brand posts across your channels — and, optionally, a blog article — with zero extra steps. No codebase access required.

Announce releases from a repo

  1. Add the repo

    In Settings → Connections, find the GitHub section and its Release announcements row. Hit Add a repo and enter the repository as owner/repo.

  2. Pick how ReachPill hears about releases

    Three ways, none of which hand over your code — see the access options below.

  3. Choose where it posts

    Pick the social channels each release should post to, and whether to also draft a blog article. At least one channel (or the blog) is required — otherwise there's nothing to generate.

  4. Choose the review style

    Review each release, auto-approve after a wait, or publish automatically. Whatever you pick, the first release always waits for your review, so you see a real post before anything goes hands-off.

Three ways to connect — no code grant

  • Public repo— ReachPill watches the repo's public releases feed. Nothing to install, nothing to grant.
  • GitHub App — install the read-only reachpill-releases app on exactly the repositories you choose. Release events arrive instantly; works for private repos. Honest limit: GitHub has no releases-only permission, so the app holds read-only Contents access — it subscribes to release events only, and you can revoke it at any time.
  • From your CI — a short GitHub Action in the repo posts each release to ReachPill with your API key. ReachPill holds no GitHub access at all.

The CI option

For the push-based route, save this as .github/workflows/reachpill-release.ymlwith a ReachPill API key in the repo's REACHPILL_API_KEY secret (the add-repo dialog generates it pre-filled for your repo):

name: Announce release
on:
  release:
    types: [published]
jobs:
  announce:
    runs-on: ubuntu-latest
    steps:
      - run: |
          curl -fsS -X POST https://app.reachpill.com/v1/release-events \
            -H "Authorization: Bearer ${{ secrets.REACHPILL_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d "$(jq -n \
              --arg repo "${{ github.repository }}" \
              --arg tag "${{ github.event.release.tag_name }}" \
              --arg title "${{ github.event.release.name }}" \
              --arg url "${{ github.event.release.html_url }}" \
              --arg body "${{ github.event.release.body }}" \
              '{repo_full_name: $repo, tag: $tag, title: $title, html_url: $url, body_markdown: $body}')"

What gets announced

  • Stable, published releases only — drafts and pre-releases are ignored.
  • One announcement per release, deduplicated: a redelivered event never posts twice.
  • Posts lead with what actually improved, grounded in your release notes and Brand DNA — never a raw changelog dump.
  • Everything rides your normal review queue, campaign reporting included.
Prefer code? The same setup is one call over MCP or the API — create_release_source to configure a repo and announce_release to push a release by hand. See Build with agents.
Next: Slack