Generate documentation PDFs on every deploy, create release notes as downloadable documents, and archive test evidence — all triggered automatically by your existing CI/CD workflow.
Some documents need to exist as PDFs. Release notes for stakeholders who don't use GitHub. Documentation snapshots for compliance. Test evidence for audits. Changelogs for non-technical teams. These are documents that people need to read, file, and reference outside the context of your codebase.
Generating them automatically in your pipeline ensures they are always current and eliminates the manual work of converting pages to PDF, renaming files, and uploading them to the right place. Every time your code ships, the documents ship with it — formatted, timestamped, and ready to distribute.
The Pretty PDF API fits naturally into this workflow. A single HTTP call with a URL or HTML payload returns a styled PDF. Wrap that call in a pipeline step and your CI/CD system handles the rest: triggering on push, storing artifacts, and notifying your team.
A complete workflow file that generates PDFs from your documentation pages on every push to main and uploads them as build artifacts.
Create .github/workflows/generate-pdfs.yml in your repository:
name: Generate Documentation PDFs
on:
push:
branches: [main]
jobs:
generate-pdfs:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Generate PDF — User Guide
run: |
curl -s -X POST https://api.prettypdfprinter.com/v1/generate/url \
-H "X-API-Key: ${{ secrets.PRETTYPDF_API_KEY }}" \
-H "Content-Type: application/json" \
-d '{"url": "https://docs.example.com/user-guide", "template": "corporate"}' \
-o pdfs/user-guide.pdf
- name: Generate PDF — API Reference
run: |
curl -s -X POST https://api.prettypdfprinter.com/v1/generate/url \
-H "X-API-Key: ${{ secrets.PRETTYPDF_API_KEY }}" \
-H "Content-Type: application/json" \
-d '{"url": "https://docs.example.com/api-reference", "template": "corporate"}' \
-o pdfs/api-reference.pdf
- name: Generate PDF — Changelog
run: |
curl -s -X POST https://api.prettypdfprinter.com/v1/generate/url \
-H "X-API-Key: ${{ secrets.PRETTYPDF_API_KEY }}" \
-H "Content-Type: application/json" \
-d '{"url": "https://docs.example.com/changelog", "template": "clean"}' \
-o pdfs/changelog.pdf
- name: Upload PDF artifacts
uses: actions/upload-artifact@v4
with:
name: documentation-pdfs
path: pdfs/
retention-days: 90Store your API key in Settings > Secrets and variables > Actions as PRETTYPDF_API_KEY. The secret is masked in logs and never exposed in workflow output. Each step generates one PDF and writes it to the pdfs/ directory. The final step uploads all generated PDFs as a downloadable build artifact with a 90-day retention period.
A .gitlab-ci.yml job that generates PDFs and stores them as GitLab CI artifacts.
Add the following job to your .gitlab-ci.yml:
generate-pdfs:
stage: deploy
image: alpine:latest
before_script:
- apk add --no-cache curl
- mkdir -p pdfs
script:
- |
for page in user-guide api-reference changelog; do
curl -s -X POST https://api.prettypdfprinter.com/v1/generate/url \
-H "X-API-Key: ${PRETTYPDF_API_KEY}" \
-H "Content-Type: application/json" \
-d "{\"url\": \"https://docs.example.com/${page}\", \"template\": \"corporate\"}" \
-o "pdfs/${page}.pdf"
echo "Generated ${page}.pdf"
done
artifacts:
paths:
- pdfs/
expire_in: 90 days
rules:
- if: $CI_COMMIT_BRANCH == "main"Store your API key in Settings > CI/CD > Variables as PRETTYPDF_API_KEY with the Masked option enabled. The variable is injected into the job environment without appearing in logs. The artifacts block makes the generated PDFs downloadable from the pipeline page in GitLab, with automatic expiration after 90 days.
A declarative Jenkinsfile that generates PDFs using credential binding and archives the results.
Add a Jenkinsfile to your repository or configure the pipeline in Jenkins:
pipeline {
agent any
environment {
PRETTYPDF_API_KEY = credentials('prettypdf-api-key')
}
stages {
stage('Generate PDFs') {
steps {
sh 'mkdir -p pdfs'
sh '''
curl -s -X POST https://api.prettypdfprinter.com/v1/generate/url \
-H "X-API-Key: ${PRETTYPDF_API_KEY}" \
-H "Content-Type: application/json" \
-d '{"url": "https://docs.example.com/user-guide", "template": "corporate"}' \
-o pdfs/user-guide.pdf
'''
sh '''
curl -s -X POST https://api.prettypdfprinter.com/v1/generate/url \
-H "X-API-Key: ${PRETTYPDF_API_KEY}" \
-H "Content-Type: application/json" \
-d '{"url": "https://docs.example.com/api-reference", "template": "corporate"}' \
-o pdfs/api-reference.pdf
'''
sh '''
curl -s -X POST https://api.prettypdfprinter.com/v1/generate/url \
-H "X-API-Key: ${PRETTYPDF_API_KEY}" \
-H "Content-Type: application/json" \
-d '{"url": "https://docs.example.com/changelog", "template": "clean"}' \
-o pdfs/changelog.pdf
'''
}
}
}
post {
success {
archiveArtifacts artifacts: 'pdfs/*.pdf', fingerprint: true
}
}
}Store your API key in Jenkins > Manage Credentials as a secret text credential with ID prettypdf-api-key. The credentials() binding injects the value into the environment variable while keeping it masked in console output. The archiveArtifacts post-action makes the PDFs available on the build page with fingerprinting enabled for traceability.
Four patterns that teams use most when integrating PDF generation into their pipelines.
Archive the current state of your documentation before each deployment. Run the PDF generation step before updating your docs site so you have a versioned PDF snapshot of what was live at the time of each release. Store these alongside your release tags for easy retrieval.
Convert your CHANGELOG or GitHub release page to a PDF on each tagged release. Send the release page URL to the API and include the version number in the filename. Distribute the resulting PDF to stakeholders who prefer reading release notes as a document rather than navigating to GitHub.
Save test report pages as PDFs after your test suite completes. When using test frameworks that generate HTML reports (pytest-html, Allure, JUnit), convert those reports to PDF and attach them as pipeline artifacts. This provides a permanent, portable record of test results for each build.
Take regular snapshots of policy pages, terms of service, and compliance documentation. Schedule a nightly or weekly pipeline job that converts these pages to timestamped PDFs. This creates an auditable trail showing what your public-facing policies said on any given date.
Guidelines for reliable, secure, and efficient PDF generation in automated pipelines.
Never commit your API key to your repository. Use your CI platform's secret management — GitHub Secrets, GitLab CI Variables with masking enabled, or Jenkins Credentials. Rotate keys periodically and use separate keys for each environment (staging, production) so you can revoke one without disrupting the other.
Network issues and temporary server load can cause individual requests to fail. Wrap your API calls in a retry loop with exponential backoff. Two or three retries with a short delay between attempts is usually sufficient to handle transient errors without significantly extending your pipeline duration.
If the source content has not changed since the last build, there is no need to regenerate the PDF. Use file checksums or Git commit hashes to detect changes. Store previously generated PDFs in your artifact cache and skip the API call when the input is unchanged. This saves API quota and speeds up your pipeline.
Name your output files with enough context to identify them later. Include the document name, version number, or date in the filename — for example, user-guide-v2.4.1-2026-02-13.pdf. This makes it easy to find specific versions in your artifact storage without opening each file.
Run PDF generation in its own pipeline stage that does not block deployment. If PDF generation fails due to a temporary API issue, your deployment should still proceed. Configure the PDF stage with continue-on-error (GitHub Actions), allow_failure: true (GitLab CI), or a try/catch block (Jenkins) so that failures are logged but do not prevent your code from shipping.
One API call per document. No browser automation, no headless Chrome, no maintenance overhead.