GET or POST for screenshot API runs
Use GET for quick URL-based runs and POST for screenshot API requests with headers, cookies, flow steps, labels or storage settings.
On this page
Use this when
- Use GET for a quick URL to screenshot, PDF, HTML or Markdown run.
- Use POST for cookies, headers, steps, file output, storage routing or longer payloads.
- Use a narrow, short-lived API key if sensitive values must ever travel through a URL.
When GET is enough and when POST is better
A screenshot API often starts with a URL in the query string. GET works well for that first test: target page, output format, viewport and cache settings in one shareable request.
POST is safer once the run becomes part of production work. Headers, cookies, HTML input, Markdown output, labels, storage settings and multi-step flows are easier to keep readable in a request body. Sensitive values also stay out of browser history, server logs and shared URLs.
Where the method changes the product path
GET is good for a quick render API call. POST is the safer choice when the same page must be checked again, labelled, sent to storage, reviewed later or tied to a release process.
RenderLog treats both methods as the same run history. A developer can start with one API call, then the team can move the same target into manual review, Check Suites, baselines and notifications without changing products.
- CI jobs can keep short render calls readable.
- Server services can send full structured requests without encoding every option into a URL.
- Teams still get generated files, logs, labels and review history after the API call finishes.