Integrating CaptureKit with Lovable & Building A Screenshot Tool

In this quick tutorial, we will see how you can integrate Lovable with CaptureKit’s Screenshot API.

And in the process we will be building a screenshot tool, that when used with your API_KEY can be used to take screenshots.

If you want to build a free tool to take screenshots with URL, you can hide the API_KEY at backend.

Let’s see how this tool works, & how you can integrate it with Lovable.

What Did I Use To Build This Integration

Below is a quick walkthrough of how this tool looks and works. Just fill in the API_KEY, the URL for which you want to take screenshot for, define format & finally toggle the button for full page screenshot small video:

Now since you know you need a prompt to Lovable, we will prepare that first.

And to prepare it, we have used ChatGPT, this is the prompt I gave to GPT to get a prompt for lovable.

Act like an expert in using no-code app builder tools like lovable. 

Build a prompt to use in lovable for the following tass. 

I want to integrate CaptureKit's Screenshot API to lovable, you can read the documentation of capturekit's api in this page - https://docs.capturekit.dev/api-reference/screenshot-api 

I want you to integrate the endpoint at the backend, from the front dashboard, give API_KEY, and URL , also give some optional parameters from the front end, like full_page, format. 

Keep them on default to, but should have option to change, in given values that is in the documentation. 

Further, below it we get the screenshot, when once done after giveng the right API key and URL, and/or option parameters. 

If full_page is used it should show the whole page in the image, I am giving you the homepage of screenshot API, the tool should be in the same theme.

Act like an expert in using no-code app builder tools like lovable. Build a prompt to use in lovable for the following tass. I want to integrate CaptureKit's Screenshot API to lovable, you can read the documentation of capturekit's api in this page - https://docs.capturekit.dev/api-reference/screenshot-api I want you to integrate the endpoint at the backend, from the front dashboard, give API_KEY, and URL , also give some optional parameters from the front end, like full_page, format. Keep them on default to, but should have option to change, in given values that is in the documentation. Further, below it we get the screenshot, when once done after giveng the right API key and URL, and/or option parameters. If full_page is used it should show the whole page in the image, I am giving you the homepage of screenshot API, the tool should be in the same theme.

I did add the Screenshot of the homepage, to have the same theme of the tool as the website is.

This is what I got in return from GPT: -

Goal: A single-page web app that calls CaptureKit’s Screenshot API from the backend and lets a user input an API Key, URL, and a few optional params (at least full_page and format). After submitting, render the resulting screenshot below the form. If full_page is enabled, the rendered preview should support full-page viewing (scrollable and zoomable) and offer a download. Docs to follow: https://docs.capturekit.dev/api-reference/screenshot-api Key reference details (endpoint & params) come from the docs. Use these allowed values: Endpoint: https://api.capturekit.dev/capture docs.capturekit.dev Required params: access_key (via header x-access-key or query), url docs.capturekit.dev Optional params (use in UI now): format: one of webp, jpeg, jpg, png, pdf (default png) docs.capturekit.dev full_page: boolean (default false) docs.capturekit.dev (Keep code structured so it’s easy to add more later like viewport_width, viewport_height, delay, device.) Requirements 1) UI / Frontend Create a responsive dashboard card with: API Key (password field) — label “API Key”, placeholder “ck_live_xxx…”, stored only client-side state but sent to backend on submit; show an eye icon to toggle visibility. URL (text field) — label “Page URL”, placeholder “https://example.com” , required, basic validation (must start with http/https). Format (select) — label “Format”, default png, options exactly: png, jpeg, jpg, webp, pdf. Full Page (switch) — label “Full page capture”, default OFF. Submit button — “Capture Screenshot”. Below the form, a Results section: When loading: skeleton/loader with “Capturing…”. On success (image formats): show the screenshot in a bordered container with: Fit-to-width preview and click to zoom (or a zoom slider). If full_page=true, preview container supports scrolling (no crop). Buttons: Download (same file returned) and Open Raw (opens the image URL in a new tab). On success (pdf): show a PDF viewer (or a “View PDF” button + download). On error: a red toast and an inline error panel showing status code + message text. Theme: Match the CaptureKit Screenshot page vibe—modern, minimal, developer-first. Use these tokens: Primary: #836AFF (buttons, accents, focus rings). Background: #f7f7f1 (page background). Text: near-black on light, with tasteful muted greys for labels. Rounded xl, subtle shadow on cards, comfortable padding. Provide dark-mode variant automatically (system preference). 2) Backend / API Route Create a secure server route /api/capture that: Accepts POST JSON body: { "access_key": "string", "url": "string", "format": "png|jpeg|jpg|webp|pdf", "full_page": true|false } Validates inputs: access_key required (non-empty). url required; must be a valid absolute URL with http/https. format must be one of the allowed values (default png if omitted). full_page defaults false if absent. Calls https://api.capturekit.dev/capture from the server (never from the client) and forwards parameters: Prefer sending access_key in header: x-access-key: (supported per docs). docs.capturekit.dev Include url, format, full_page as query params. Handles binary responses: If format is not pdf, return the raw image buffer to the client with the correct Content-Type (e.g., image/png) and also make it reachable by a temporary object URL in the frontend. If pdf, return with application/pdf. Robust error handling: If upstream returns non-200, forward status and a JSON body { error: "", status: }. 3) Frontend–Backend Wiring On submit: Disable the form + show loading state. fetch('/api/capture', { method: 'POST', body: JSON.stringify({...}) }). If response is image/* or application/pdf, convert to blob, build an object URL with URL.createObjectURL(blob), and display it accordingly. Add a small “cURL” code preview panel that updates live to show the equivalent direct API call: curl -X GET "https://api.capturekit.dev/capture?url=&format=&full_page=" \ -H "x-access-key: " (Clearly mark this as a helper, not used by the app.) 4) Defaults & UX polish Defaults: format=png, full_page=false. docs.capturekit.dev Keep layout to a two-column form on desktop, single column on mobile. Persist last used values to localStorage (API key included only if user checks “Remember key on this device”). Add tiny helper text under Format: “Allowed: webp, jpeg, jpg, png, pdf”. Add helper under Full page: “Scroll-stitches the whole page before capture.” Include a footer link “View CaptureKit docs” pointing to the docs page. 5) Extensibility (code comments, not UI) Leave TODOs showing where to easily add more params later (viewport_width, viewport_height, delay, device) per docs. docs.capturekit.dev Acceptance criteria I can enter API Key + URL, hit Capture, and see a screenshot preview. Toggling Full page results in a long, scrollable preview of the entire page. Changing Format to pdf yields a PDF viewer/download. Errors from the CaptureKit API show a clear toast and an inline explanation. The app theme matches the specified tokens and feels like CaptureKit’s style. Reference: All parameter names, endpoint, allowed format values, and the x-access-key header support are taken from the CaptureKit docs page.

GPT read the docs, understood all the parameters and finally prepared a prompt that we can feed in Lovable.

Pretty cool, now we head to Lovable and put this prompt.

It gives you free 5 daily credits and 30 in total. It took some time and the first version of the tool was available.

We iterated it a little and the final version was ready. And so this way, you can also build tools by using this combo.

And here is the public link of this tool — https://preview--capture-snap.lovable.app/

Common Pitfalls & Troubleshooting while Integrating CaptureKit with Lovable

When I first built this tool on Lovable with CaptureKit’s API, everything seemed smooth… until I hit a few snags. Here are the issues you might face, what they actually mean, and how to fix them:

1. CORS Issue
This was the first roadblock I ran into. At the start, my Lovable app showed a “demo screenshot” instead of the real one. Why? Because of something called CORS (Cross-Origin Resource Sharing).

• In plain words: your browser doesn’t allow calling some APIs directly for security reasons, unless the API explicitly says “this site is safe.”
• So, when I tested locally, the CaptureKit API was blocked by my browser.
• The fix was simple: I published my Lovable page to a public link, and suddenly the screenshots started working for real.

💡 Tip: If you’re still stuck, you can always send the API request via a backend (instead of directly from the browser) to bypass CORS completely.

2. Invalid API Key
Another common hiccup is using the wrong API key. If the key is missing, expired, or mistyped, CaptureKit won’t process your request.

• You’ll usually see an error like “401 Unauthorized” or “Invalid access_key” in the response.
• Always double-check that you copied the key correctly from your CaptureKit dashboard.
• Also make sure you’re passing it in the right place: as the x-access-key header (or as access_key in the query).

This is how the CaptureKit’s Dashboard looks like: —

3. Slow Loads or Delayed Screenshots
Sometimes, your screenshot might take a little longer than expected. This usually happens if:

• The target page is heavy (lots of images, scripts, or ads).
• The page has elements that take time to fully render.

CaptureKit gives you optional parameters that help here:

• delay → tells CaptureKit to “wait a few seconds before snapping” so everything loads. Example: delay=3 waits 3 seconds.
• viewport_height → controls how tall the browser window is. A larger height can help capture pages with sticky headers or dynamic content.

💡 Pro tip: Start with defaults, then adjust these parameters only if you see missing or half-loaded content in your screenshots. You can refer to the documentation when stuck.

What Else You Can Do Next

By now, you’ve seen the usual bumps in the road CORS errors, invalid keys, or slow loads and how to get past them. Once the basics are steady, the fun part begins: stretching this tool to do more than just a single screenshot on demand.

1. Add More Optional Parameters
Right now, we only played with full_page and format, but CaptureKit actually gives you more flexibility:

• device → Pretend you’re capturing from a desktop, tablet, or phone. Great for checking how responsive a site looks.
• viewport_width / viewport_height → Control the exact size of the browser window.
• delay → Tell CaptureKit to wait a few seconds before snapping, perfect for pages that load slowly or have animations.

You can expose these in Lovable as extra toggles or dropdowns, so users get more control without touching the code.

2. Chain It With Other APIs
Screenshots are usually part of a bigger workflow. You can hook this up with other apps to create something really useful:

• Send every new screenshot straight to Google Drive or Dropbox.
• Post captures to Slack or Teams, so your team gets updates without asking.
• Plug into reporting dashboards where screenshots sit alongside analytics.

It moves your tool from “just a screenshot app” into a real automation system.

3. Schedule Screenshots With Lovable Automations
Why click a button every time? Lovable makes it possible to set your captures on autopilot:

• Run a screenshot every morning at 9 AM to check if your site looks fine.
• Schedule weekly competitor captures to track changes over time.
• Combine this with auto-upload, and you’ve got yourself a neat web archive that builds itself.

Additional Resources

1. Best Screenshot APIs for Developers
2. Automate Website Screenshot using n8n & Screenshot API
3. 4 Best URLbox Alternatives for Screenshot API