Switching from another API
How common options of other screenshot and PDF APIs map to render-bolt, and a checklist for moving over.
Most screenshot and PDF APIs share the same ideas. This table maps the usual options:
| You want | render-bolt option |
|---|---|
| Full-page screenshot | full_page: true |
| Capture one element | selector: "#pricing" |
| Retina / 2x | device_scale_factor: 2 |
| Block ads | block_ads: true |
| Hide cookie banners | block_cookie_banners: true |
| Dark mode | dark_mode: true |
| Wait for an element | wait_for_selector: ".loaded" |
| Extra delay | delay: 1500 |
| Viewport size | viewport: { width: 1440, height: 900 } |
| Return a link instead of the file | response_type: "url" |
| Page to Markdown | POST /v1/extract { url } |
Checklist#
- Create a free key and run your three most common requests in the playground.
- Compare the output with what you have today, especially fonts, cookie banners and lazy images.
- Replace the base URL and the auth header. render-bolt uses
Authorization: Bearer <key>, oraccess_keyonGET. - Map error handling to our error codes. Failed renders aren't counted, so you don't need to dedupe retries for billing.
- Run both services side by side for a few days if the output matters, then switch.
Where we differ#
- One key covers screenshots, PDFs and Markdown extraction.
- Responses are synchronous: the body is the file. There are no webhooks or async jobs, and no direct upload to your own storage.
- Video capture and AVIF/SVG output are not supported.
Honest side-by-sides with specific services are on the comparison pages.
Stuck? Write to [email protected] with the request you sent and the error code you got back.