Today, the new version of ScreenshotOne API was deployed to production that enables a retries mechanism when uploading to an S3 storage and more granular error handling.
Improved uploading and error handling to S3-compatible storage
Today, the new version of ScreenshotOne API was deployed to production that enables a retries mechanism when uploading to an S3 storage and more granular error handling.
ScreenshotOne supports direct file upload of screenshots to any S3-compatible storage.
But often what happens is that storage can return a 500 error when you upload screenshots to them and then the overall request fails. You need to retry and render a screenshot again. By the way, failed requests are not counted. And check out our simple guide on handling ScreenshotOne API errors.
Since today, the overflow flow has been improved thanks to one of our customers who requested that.
ScreenshotOne will retry at least 5 times to re-upload the file to your storage and if it doesn’t happen, you will get a better error than the generic one—“storage_returned_transient_error”.
In that release, there is also a new error added like “storage_access_denied” to see if your credentials are expired or you misconfigured them.
That’s all for today. I wish you to enjoy your day and as always, feel free to reach out to hey@screenshotone.com if you have any questions.
Interviews, tips, guides, industry best practices, and news.
Now you can detect fonts used by any website with ScreenshotOne API in just one simple API call.
May was a great month and full of new and exciting updates. Let's check them out quickly.
There is a set of use cases when you want to fail screenshot rendering and retry it if the content of the page is missing a string.
Exhaustive documentation, ready SDKs, no-code tools, and other automation to help you render website screenshots and outsource all the boring work related to that to us.