How to Capture a Password-Protected Web App Screenshot with Make

Short answer: Make orchestrates the workflow; it does not itself provide a browser that can log into any arbitrary web app. Use Make’s HTTP app to call a browser screenshot API. The browser must be able to reach the app and have valid authorized login state, such as a supported saved authenticated profile. Then route the returned image data to storage and verify that it shows the intended page rather than a login or error screen.

This guide describes the configuration pattern, not a tested Make scenario. Confirm the HTTP module’s current field names, binary response handling, authentication support, target network access, and the app’s automation rules when you implement it. Make recommends its HTTP app for connecting to services without a built-in integration. Make: Connect an application

1. Check access, authentication, and network reachability

Before building the scenario, establish how the target page can be opened and who may automate it. The browser service—not Make—loads and renders the page.

Authorization: Confirm you are allowed to automate the account and capture the page. Treat the image as potentially sensitive account data.
Reachability: Determine whether the page is public to the browser service or only available on a private network. A cloud browser cannot be assumed to reach internal pages.
Login method: Identify whether login uses a reusable session, SSO, MFA, device trust, or a short-lived session. These can affect whether saved browser state works.
Capture scope: Decide whether you need the visible viewport, a full-page image, or a specific element, and limit capture to the necessary information.
Destination: Choose storage with appropriate access permissions and retention for the captured data.

Make’s on-premise agent documentation describes connecting to an application API through its HTTP Agent. That does not establish that a separate remote browser service can reach the same private web page. Check where the browser runs and how network access is provided. Make: On-premise agent

2. Establish reusable browser authentication

A screenshot request for a protected page must start with valid browser authentication. One documented approach is a saved authenticated browser profile that is loaded before the page is rendered. Browserless documents this capability; Playwright also documents saving and reusing authenticated browser state. A saved session is not a guarantee of compatibility with every app, and it may expire, be revoked, or be rejected.

Use an authentication method approved for the target app and your organization.
Establish the logged-in browser state using the browser provider’s supported flow. Follow its instructions for profile creation and storage; this dossier does not specify provider setup fields or claim a tested profile.
Check that the state remains valid for the account’s session lifetime and renewal rules.
Restrict access to the profile and treat its state like a password: anyone who can use it may be able to act as the logged-in user.

Browserless describes loading saved authenticated state before rendering, while Playwright describes reusable authentication state. Neither capability means every SSO, MFA, device-trust, or automation policy will accept a saved session. Browserless: Authenticated Profiles · Playwright: Authentication

3. Configure Make to call the screenshot API

Add an HTTP request step to the Make scenario. Configure it to send the screenshot service’s documented request, including the target URL, authentication/profile reference, and capture settings required by that service. The exact endpoint, payload fields, and profile identifier depend on the provider; do not copy an endpoint or parameter name without checking that provider’s current documentation.

In Make, add the HTTP app’s request module and set the method and URL specified by the screenshot API.
Configure the request body and authorization exactly as the screenshot provider documents. For Browserless, consult its screenshot API reference for the POST request format and available capture settings.
Supply the intended page URL and the supported means of selecting the saved authenticated profile.
Choose viewport or full-page capture and, if supported and needed, a CSS selector for a specific region.
Keep API credentials in Make’s credential/keychain handling where supported. Avoid putting tokens, passwords, or session state in scenario text or ordinary logs.
Set the response handling so the returned image data is preserved as binary data for the next module. Verify the actual output bundle before routing it.

Make documents keychain storage for HTTP API key and Basic Auth credential types. Browserless documents a screenshot API that returns image data, with capture options. Check the current documentation for the precise request schema and response format. Make: Keys and certificates · Browserless: Screenshot API

4. Route the image and verify the result

Connect the HTTP response to a storage or attachment module that accepts the returned image data. The field mapping and destination module depend on your scenario; verify them with a real authorized run before relying on the automation.

Map the binary image response to the destination’s file or attachment input.
Set a useful filename and preserve or explicitly assign the image content type and extension if the destination requires them.
Open the stored image and confirm it shows the intended authenticated page, not a login page, CAPTCHA, access-denied screen, blank page, or browser error.
Check the captured account and region for sensitive information before sharing the destination link or attachment.
Decide how failed requests and invalid captures should be reported or retried; avoid silently treating every HTTP success as a correct screenshot.

Browserless notes that blank captures, CAPTCHA pages, and access-denied responses may indicate that a site blocks automation. A successful HTTP response alone does not prove the desired authenticated content was captured. Browserless: Screenshot API

5. Choose the browser approach that fits the task

Need	Approach	Check before relying on it
Navigate, render, and capture in one request	Call a screenshot REST API from Make’s HTTP app.	Confirm the endpoint accepts the required authentication state and capture options, and returns image data in a form Make can route.
Capture pages that require a login	Use a supported authenticated browser profile or equivalent reusable browser state.	Confirm the session is valid, authorized, protected, and compatible with the app’s SSO/MFA and session policies.
Several actions or decisions before capture	Use a browser-control session or a Playwright/Puppeteer script that can perform the interaction sequence.	Confirm the browser environment can reach the app and that the flow can securely obtain and renew authentication.
App is only reachable on a private network	Design network access for the browser itself; consider an in-network browser or an architecture explicitly supported by the provider.	Make’s HTTP Agent documentation concerns application API access and does not prove remote browser reachability.

Browserless documents both a one-request screenshot REST API and WebSocket connections for browser-control libraries. Select based on whether one capture request is enough or the workflow needs interactive steps. Browserless: REST APIs · Browserless: OpenAPI overview

6. Keep credentials and captured data safe

Use Make’s credential storage for supported API key or Basic Auth credentials rather than embedding secrets in scenario text.
Limit who can manage shared Make connections and who can use the authenticated browser profile.
Do not pass passwords or session cookies through ordinary scenario text or logs.
Give the destination appropriate permissions and retention, because screenshots can expose confidential account details.
Capture only the needed page or region and review the image before distributing it.
Revisit access when a person, scenario, account, or browser profile no longer needs it.

Make describes connection management and keychain handling; Browserless describes reusable authenticated state. Those capabilities make credential protection part of the scenario design. Make: Connect an application · Make: Keys and certificates · Browserless: Authenticated Profiles

7. Troubleshooting

Symptom	Likely cause	What to check or change
The image shows a login page	The browser did not load the saved authenticated state, the session expired, or the app rejected it.	Check that the correct profile is selected and still valid. Review the app’s SSO, MFA, device-trust, and session rules; use an approved supported authentication flow.
The result is blank	The page failed to load, content rendered after capture, the browser could not reach the app, or the site blocked automation.	Check browser network reachability and provider capture settings. Wait for an appropriate page condition if supported, then inspect the resulting image rather than relying only on HTTP status.
The image contains a CAPTCHA or access-denied page	The site may block or challenge automated browsers.	Confirm the app permits the automation and use an approved access method. Do not assume that changing screenshot settings resolves an access policy.
Make reports an HTTP error	The request method, endpoint, authorization, request body, or target URL may be wrong, or the service may reject the request.	Compare the configured request with the screenshot provider’s current API documentation. Inspect the error response without exposing credentials in logs.
The next module cannot save the image	The HTTP response may be mapped as text/JSON instead of binary image data, or the destination expects a different file input.	Inspect Make’s output bundle, map the image data to the destination’s file field, and set filename/content type as required by that module.
Internal app works in a local browser but not in the capture service	The remote browser cannot reach the private network or requires a network path not configured for it.	Check the browser’s network location and provider-supported private connectivity. Make’s HTTP Agent access to an application API does not by itself solve browser access.
Screenshot succeeds sometimes but not consistently	Authentication state may expire, page content may load asynchronously, or network and site behavior may vary.	Check session renewal and wait conditions; verify each image and define failure handling in the scenario. Avoid assuming a fixed session lifetime or capture duration.

8. Performance, reliability, and cost

Capture time depends on the target site’s load behavior, authentication, network path, and the screenshot service’s settings. The reviewed documentation establishes no benchmark for this workflow, so measure it in your own scenario rather than planning around an assumed duration. Full-page captures and pages with late-loading content may need more waiting and can produce larger image data than a viewport capture.

Reliability: Check the page state represented in the image, not only whether the HTTP module completed. Sessions can expire or be rejected, and CAPTCHA or access-denied pages can look like successful captures at the transport level.
Retries: Decide which failures are safe to retry. A retry cannot fix invalid credentials or blocked access; repeated requests can also obscure the original failure if logs are not useful.
Storage: Account for image retention, destination permissions, and the sensitivity of each screenshot.
Cost: The research reviewed here did not verify Make or Browserless prices. Check the current plans and billing terms for the services you choose, plus any storage or execution costs in your own setup.
Operations: Monitor whether the authenticated state remains usable and whether the screenshot still captures the intended page after app changes.

Or skip the browser setup

If you only need a screenshot of a URL that ScreenshotNeo can access, make one GET request. See the ScreenshotNeo API documentation for options and authentication setup.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before the capture. Bot checks, blank pages, and failed loads are never billed, and each response identifies the page verdict and billing status. Its MCP server lets AI agents use screenshot tools. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Learn about ScreenshotNeo or sign up free for 1,000 screenshots a month with no card.

FAQ

Can Make log in to any password-protected app by itself?

No. Make can orchestrate an HTTP request to a screenshot service, but the browser and its authorized login state must be provided by the browser workflow you choose.

Will a saved browser profile work with every SSO or MFA setup?

No. Reusable state is a documented technique, not a promise that every app will accept it. Check the target app’s authentication and automation policies.

Can a cloud screenshot service capture an internal company page?

Only if the browser has a supported network path to that page. Make’s on-premise HTTP Agent documentation alone does not establish that a remote browser can reach it.

What proves the capture is correct?

Inspect the image and verify the intended authenticated content is present. An HTTP success by itself is not sufficient.