**OFFICIAL DOCUMENTATION AT: ** https://rasterwise.gitbook.io/docs/
All the parameters described in the official documentation work the same for the RapidAPI version.

Generating screenshots just requires a single request to the GetScreenshot API.
By design, GetScreenshot only supports GET requests. In our experience this favors simplicity, usability and newbie friendliness.

To see some examples on how to generate a basic screenshot in the GetScreenshot API with some popular programming languages, please visit: https://rasterwise.gitbook.io/docs/

How does GetScreenshot capture screenshots?

As many services in this space, GetScreenshot uses Google’s Headless Chrome implementation (Puppeteer) to generate your screenshots.
When you send a request to our service the following things will happen:
The server will launch a headless Chrome session.
Then it will perform a controlled navigation that emulates a common user navigation, based on the preferences set in your request.
Upon loading the passed website, our script will snap a screenshot and perform any requested post-processing.
The script will save the screenshot to a secure static storage location (a secure Amazon S3 Bucket).
The script will send a response back to your client, with the URL of your screenshot.
You can retrieve the resulting screenshot for the following 15 days. After 15 days, the object will get deleted forever.
The script that capture screenshots is highly tuned to return accurate renderings. Under the hood GetScreenshot has three capturing modes that cover multiple edge cases.
GetScreenshot determines automatically which one is the best fit for the page you’re trying to capture and deals with animations, viewport height units, lazy-loaded elements and more.

Why should I use GetScreenshot instead of writing my own implementation?

We definitely asked this question ourselves when releasing this API. Also there are several other services in this space that offer similar APIs, so it’s fair to assume that there’s demand for this kind of managed service, so there must be a reason to avoid a self-managed implementation.
We really don’t have a concrete answer, but here is what we believe are the top reasons to choose a service like GetScreenshot:

Using Puppeteer is easy. Making it work the right way is hard.
If you decide to go and write your own service on top of Puppeteer you will quickly find how hard is to get its synchronous behavior right.
It’s very likely that you will spend countless hours trying to tweak the execution of your Puppeteer script just to address edge cases. We have already done that, and we keep doing it. We addressed several edge cases and we keep updating our underlying logic to address more.

If your job is to write beautiful and performant code for complex problems, you will hate writing your own implementation of this.
Sounds over dramatical, but is true. There’s nothing glamorous or exciting about writing a screenshot capture service for your own application. You are going to spend countless hours trying to understand why a certain particular DOM element is not showing or why Puppeteer for some reason is capturing a complete white page.
We build GetScreenshot and offer it at a low price point, so you can go and work on the important stuff.
If you’re passionate about this area of work, then we definitely encourage you to go and test writing your own implementation. Otherwise, we encourage you to give us a try.

You actually need to provide infrastructure resources, just for this.
Amazon EC2? Amazon ECS? Digital Ocean Droplet? Google GCE? Heroku App? A Linux Machine in the janitorial closet?
Whatever it is, you need something to run your own screenshot capture service, and that means dealing with provisioning and paying for under-used resources.
Our recommendation is to not waste time on this and simply go with something already implemented and exposed through a secure RESTful API. That’s where we come. At our price point, it’s just easier and potentially cheaper. There’s no point in managing this yourself.

Your time as a developer is actually more expensive than you think.
Let’s say that you are a mid-level developer in a small market earning $90K USD per year, working 40 hours per week. Your effective hour rate is: $47 USD per hour.
Now, writing your own super basic implementation of this will take at least 5 hours. But that’s just getting a simple prototype ready. Realistically you can spend +30 hours just trying to address rendering issues, spinning and calibrating resources, creating and exposing a RESTful API, writing documentation, testing, etc. And then you also need to integrate this into whatever you’re planning to use, support it, and likely expand it to address some alternative uses.
So in a realistic scenario, you can easily spend more than a week writing something like this, and then a an hour every month supporting it. That’s almost $2000 USD of your time, just to write a service like this, plus another $500 USD or so, just to support it every year. And this doesn’t include whatever you’re paying to run it.
GetScreenshot P90 of screenshot needs, is about 5000 captures which you can get with a $10 USD a month plan. That’s $120 USD a year.
So the question is: What sounds better? Spending +$2500 worth of your time and stress to write a similar service or pay $120 USD to someone else and let them deal with it?
If you’re still not convinced about the price, please let us know. We can always work out something based on your specific needs.