GitHub Actions: Auto-Generate a Flipbook on Every Release

If your docs, release notes, or product catalog live as a PDF in your repo, there's no reason to publish the flipbook by hand. With GitHub Actions and the FlipLink CLI, every time you cut a release you can build the PDF, turn it into a published flipbook, and post the live URL straight back onto the release — all without touching the dashboard.

This is the GitHub-native version of CI/CD flipbook publishing. If you use a different runner (GitLab CI, CircleCI, a cron box), the steps map cleanly — only the YAML shape changes.

What we're building

A workflow that triggers on a published release and:

1. Checks out the repo and builds (or locates) the PDF you want to publish.
2. Installs the FlipLink CLI.
3. Creates and publishes a flipbook from that PDF, authenticating with an API key stored as a repo secret.
4. Captures the live flipbook URL from JSON output.
5. Comments that URL back on the release so your team gets the link instantly.

It's a textbook bit of automation: an event fires, a script runs, an artifact ships.

Step 1 — Store your API key as a repo secret

Never paste an API key into a workflow file. Workflow files live in your repo — anyone with read access (and every fork) can see them. Use an encrypted secret instead:

1. Sign in at https://go.fliplink.me, open the Subscription page, and copy your API key.
2. In your GitHub repo, go to Settings → Secrets and variables → Actions.
3. Click New repository secret.
4. Name it FLIPLINK_API_KEY and paste the key as the value.
5. Click Add secret.

The workflow reads it via secrets.FLIPLINK_API_KEY and exposes it to the CLI as the FLIPLINK_API_KEY environment variable. The CLI checks that env var automatically, so there's no config set-key step needed in CI.

Step 2 — The workflow file

Create .github/workflows/publish-flipbook.yml:

name: Publish flipbook on release

on:
  release:
    types: [published]

permissions:
  contents: write   # needed to edit the release notes in the last step

jobs:
  flipbook:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      # Replace this with however you produce the PDF.
      # If the PDF is committed in the repo, you can delete this step.
      - name: Build the PDF
        run: |
          mkdir -p dist
          # e.g. your doc tooling outputs dist/release-notes.pdf
          ls -lh dist/release-notes.pdf

      - name: Install FlipLink CLI
        run: npm install -g fliplink-cli

      - name: Create and publish flipbook
        id: flipbook
        env:
          FLIPLINK_API_KEY: ${{ secrets.FLIPLINK_API_KEY }}
        run: |
          ID=$(fliplink flipbook create ./dist/release-notes.pdf \
            --title "Release ${{ github.event.release.tag_name }}" \
            --name "release-${{ github.event.release.tag_name }}" \
            --json | jq -r '.ID')

          fliplink flipbook publish "$ID"

          URL=$(fliplink flipbook share-link "$ID" --json | jq -r '.URL')

          echo "id=$ID" >> "$GITHUB_OUTPUT"
          echo "url=$URL" >> "$GITHUB_OUTPUT"
          echo "Published flipbook: $URL"

      - name: Comment the URL on the release
        uses: actions/github-script@v7
        with:
          script: |
            const url = "${{ steps.flipbook.outputs.url }}";
            const release = context.payload.release;
            await github.rest.repos.updateRelease({
              owner: context.repo.owner,
              repo: context.repo.repo,
              release_id: release.id,
              body: `${release.body || ""}\n\nFlipbook published: ${url}`
            });

A few notes on the create step:

• fliplink flipbook create ./path.pdf uploads the PDF and returns the new flipbook. With --json you get the raw response, and jq -r '.ID' pulls out the ID.
• fliplink flipbook publish "$ID" flips it live. (Creating a flipbook does not publish it — publishing is a separate, explicit step.)
• fliplink flipbook share-link "$ID" returns the public viewer URL, which we capture the same way with jq.
• We write id and url to $GITHUB_OUTPUT so later steps can reference them as steps.flipbook.outputs.url.

Everything here uses only documented CLI commands and the --json flag. If you need an action the CLI doesn't wrap, drop down to the fliplink api escape hatch — see the CLI docs for the full surface, or the API reference for every endpoint.

🚀

Try FlipLink Free

Convert your PDF in seconds. No sign-up, no credit card — just upload and go.

Drop your PDF here or click to browse

Max 40MB

Paid plans from $39 raise this to 150 MB.

Step 3 — Commenting the URL back

The cleanest way to surface the URL is to comment it on the release itself. The actions/github-script step above does that. If you prefer the GitHub CLI (gh is preinstalled on GitHub-hosted runners), this one-liner works too:

      - name: Comment via gh
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh release view "${{ github.event.release.tag_name }}" \
            --json body --jq '.body' > old-body.txt
          printf '\n\nFlipbook: %s\n' "${{ steps.flipbook.outputs.url }}" >> old-body.txt
          gh release edit "${{ github.event.release.tag_name }}" \
            --notes-file old-body.txt

That appends the flipbook link to the release notes so it's visible right where people read the changelog. Pick whichever fits your team's habits — both read the URL from the same steps.flipbook.outputs.url.

Caching and performance notes

A few things that keep this workflow fast and predictable:

• Cache npm. Add cache: npm to the setup-node step if your repo has a lockfile — it speeds up installing the CLI and any PDF tooling on repeat runs.
• Watch the rate limit. The FlipLink API allows 300 requests per minute per key. A single release publishes one flipbook, so you're nowhere near the ceiling — but if you fan out to many PDFs in one job, space the calls.
• Branch on failure. The CLI exits 0 on success, 1 on a request/HTTP error, and 2 on an application error. Because each command in the run block can fail, the step fails loudly if anything goes wrong — which is exactly what you want in CI.
• Keep the trigger tight. types: [published] means the workflow runs once, when you actually publish a release — not on drafts or pre-publish edits. That avoids accidental duplicate flipbooks.

Wrapping up

With one workflow file and one repo secret, every release now ships a published flipbook and posts the link back to your team — zero manual steps. From here you can batch-convert a whole folder, script richer pipelines with jq, or move logic into an AI agent. The patterns all build on the same CLI.

Related Reading

• Getting Started with the FlipLink CLI
• Automate Flipbook Publishing in Your CI/CD Pipeline
• CLI documentation
• FlipLink API reference
• What is automation? (glossary)