Set format to pdf on the screenshot request and let a real browser load the URL, execute page JavaScript, apply print CSS, and export a document. Use it for controlled reports, public records, documentation, and review copies without packaging a browser into your application.
curl -X POST https://api.prod.ss.snapshot-site.com/api/v1/screenshotx-snapshotsiteapi-key: YOUR_API_KEY
There is no separate PDF service to integrate. Send the page URL to the screenshot endpoint with format set to pdf. The browser loads the document and exports it with backgrounds and applicable print styles.
Swap format to pdf on an existing screenshot request — no new integration.
PDF output uses the browser's document export path. The fullSize option controls screenshots and is not required to paginate a PDF.
hideCookie and hide still work, so exported documents don't carry banners or debug UI.
A page may intentionally change under print media. Test the generated document rather than assuming it will match a PNG screenshot.
Get an API key from the console
POST a URL to /api/v1/screenshot with format set to pdf
Let print CSS and CSS page size rules control document pagination
Download the returned PDF URL
Capture a full-length dashboard page as a document instead of an image.
curl --request POST \
--url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
--header 'Content-Type: application/json' \
--header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
--data '{
"url": "https://app.example.com/reports/quarterly",
"format": "pdf",
"width": 1440,
"hideCookie": true
}'
A PDF generator does more than copy visible pixels into a file. The browser must navigate to the page, load its fonts and images, run the JavaScript required to build the document, switch into its PDF rendering path, and paginate the result. A dashboard that looks correct on screen can still produce poor page breaks, missing backgrounds, or clipped charts when exported.
Snapshot Site uses the same URL-based request model as its screenshot API. Set format to pdf and keep the API key in a server-side header. This makes PDF output a small change for teams that already capture PNG, JPEG, or WebP assets.
The input remains an HTTP or HTTPS URL. If the document begins as a template, expose it through a controlled preview route. This gives relative assets, fonts, and JavaScript a real origin and lets a developer inspect exactly what the browser will load.
Interactive navigation, sticky controls, chat launchers, and filter panels often belong on screen but not in a document. Use print media rules to hide controls that add no value in the exported record. Keep the underlying information in semantic HTML so the print layout does not depend on a canvas screenshot of the entire application.
Do not assume that fullSize is the PDF equivalent of “include everything.” That option controls image capture. PDF generation uses browser pagination, which is influenced by page size and print CSS. Test both formats when you need an image preview and a document because they are different outputs.
Long cards and tables can split across two pages. Use CSS properties such as break-inside, break-before, and break-after where a section must remain together or start on a new page. Avoid applying “never break” to every component: one element taller than a sheet cannot fit and may create a worse result.
Headers and footers need the same discipline. A fixed screen header is not automatically a useful repeating document header. Build document-specific context into the source page when every sheet needs an identifier, reporting period, or confidentiality marker.
Charts, client-rendered tables, and web fonts may appear after the initial document response. Prefer a preview route that has all required data before it declares itself ready. Use a small delay only for work that genuinely completes after navigation, and avoid live animations in the print view.
When a third-party embed is optional, replace it with a stable summary for the PDF. A document should not fail because an analytics widget, advertising request, or external dashboard is temporarily unavailable.
A scheduled backend job can build a report URL for a known period, request a PDF, validate the response, and store the document under the report revision. The Screenshot Scheduler guide shows how to separate the trigger from the rendering request and how to avoid overlapping runs.
Documentation teams can export a guide for offline review or attach a dated copy to a release record. Use a stable route and keep the source URL next to the generated file. If visual evidence rather than printable text is the objective, use a full-page screenshot instead.
A PDF can record the visible state of a policy, pricing page, or public notice at a specific time. Store the source URL, capture time, request options, and resulting file together. A generated document is useful evidence, but it does not by itself establish legal authenticity or permission to archive the source.
Invoice, receipt, and account-summary routes can be exported when the rendering environment is allowed to reach them safely. Never expose permanent public links containing personal or financial data simply to make capture easier. Use synthetic data for development and a reviewed security design for production.
Keep x-snapshotsiteapi-key in a secret manager and invoke the API from a trusted backend, worker, or automation platform. Do not embed it in a page, downloadable document, query string, or client-side application bundle.
Validate the target URL before creating a job. If customers control the target, apply an allowlist or other destination policy appropriate to the product. Sanitize logged URLs because query parameters may contain private identifiers.
After generation, verify that the response is successful before publishing a link. Store documents with access controls that match their content, define a retention policy, and avoid regenerating unchanged reports on every download.
PDF rendering usually performs more document work than a viewport image. Generate it when the underlying content revision changes, not for every reader. Queue large batches, limit concurrency, and add retries only for retryable failures.
Use deterministic report identifiers to make jobs idempotent. If the same schedule fires twice, both workers should resolve to the same intended output rather than creating two unrelated copies. For monitoring many documents, spread requests across the available window instead of creating a burst at exactly midnight.
POST the HTTP or HTTPS URL to the screenshot endpoint and set format to pdf. The response contains the generated document location when rendering succeeds.
Yes. A real browser loads the page before export. Add a measured delay when client-side content or charts settle after navigation.
No. fullSize controls whether an image screenshot includes the scrollable page. PDF output uses the browser's PDF export and pagination path.
The browser PDF renderer can apply print-oriented page behavior and CSS page-size rules. Test your actual stylesheet because screen and print layouts may differ intentionally.
Use hideCookie for common consent overlays and supported cleanup controls for page-specific elements. Confirm the final document after cleanup.
It can export a reachable invoice preview page. Protect personal data, avoid permanent public invoice URLs, and use approved access patterns for sensitive documents.
Browser pagination follows document dimensions and print CSS. Review @page, break-before, break-after, and break-inside rules in the source page.
Use PDF for documents and printing, PNG for lossless UI detail, and WebP or JPEG for lighter visual previews. Choose by downstream handling rather than file extension alone.
Start with a representative document route, verify its print stylesheet and pagination, then integrate the same request into your backend workflow.