Postman is useful when you want to inspect the exact request and response before writing integration code. Start with a target URL, add your API key, choose an output format, then compare the response evidence.
For the fastest setup, build the request in the API Builder first, copy the generated cURL or URL shape, and move the same parameters into Postman.
Basic HTML request
Use a basic request when the source HTML already contains the data your parser needs.
| Field | Example |
|---|---|
| Method | GET |
| URL | https://scraperfly.com/api/v1/get |
| url | https://example.com |
| format | html |
Rendered page request
When the initial HTML is empty or missing expected content, test rendering in Postman before making browser execution the default for a workflow.
| Parameter | Use |
|---|---|
| render=true | Run the page in a browser before capture. |
| render_wait | Wait for late-loading content only when evidence shows it is needed. |
| format=markdown | Return readable content for AI, review, or RAG workflows. |
Move from Postman to production
Postman is a validation step, not the final architecture. Once the response is proven, copy the same parameter set into your backend, job runner, or ingestion pipeline.
Use the API Builder whenever you want to compare request formats visually before sending the same shape from Postman.
FAQ
Should I start in Postman or the API Builder?
Use the API Builder to shape the request quickly, then move the generated URL or cURL command into Postman if you want a manual testing collection.
Can Postman test screenshots and PDFs?
Yes. Use screenshot or PDF output options when the workflow needs visual proof or archive-ready files.
Should Postman collections store production API keys?
Keep API keys in Postman variables or environment settings, and avoid hard-coding secrets into shared collections.