How to Capture a Webpage Behind Basic Authentication with Make

To request a webpage protected by HTTP Basic Authentication in Make, add HTTP > Make a request, choose Basic Auth, create or select a credential keychain, enter the page’s HTTPS URL, and set the method to GET. Run the module and inspect its response bundle. Turn on Parse response if you want Make to expose structured response data for mapping into later modules.

This retrieves the server’s HTTP response. It does not, by itself, render the page in a browser or run client-side JavaScript. If you need a visual screenshot, or the visible page only appears after browser-side code or an interactive login, see the browser limitation and ScreenshotNeo option below.

Configure a Basic Auth request in Make

1. Open a scenario in Make and add HTTP > Make a request. Use HTTP app version 4 when available; legacy scenarios using version 3 can show different controls. Make describes the current HTTP app and its version selector in its HTTP app announcement.
2. Set Authentication type to Basic Auth.
3. In the credential or keychain field, create a keychain or select an existing one. Enter the username and password required by the website. The target may use a service ID as the username and an API key as the password, so follow that site’s instructions instead of assuming these are a person’s normal login details. Make documents this credential setup in its keys and keychains guide.
4. Enter the full page URL, beginning with https://.
5. Choose GET. Leave the body empty unless the target endpoint specifically requires one.
6. Set Parse response to Yes if downstream modules need fields from a parseable response. Save and run the module once, then inspect the output bundle before mapping it into later steps.

Make’s HTTP app documentation says its requests require HTTPS and that it rejects unverified self-signed certificates. Use the target’s valid HTTPS endpoint; do not work around certificate validation by sending the request over plain HTTP. See the Make HTTP app documentation.

What Basic Auth sends

Basic Auth sends a username and password as a Base64-encoded credential value. Base64 is encoding, not encryption, so HTTPS protects the credentials while they travel between Make and the server. Store the pair in Make’s dedicated credential field instead of writing it into a URL, query parameter, or manually constructed header. Make’s keychain documentation describes storing Basic Auth credentials as a keychain.

Use credentials issued for the protected resource and grant only the access the workflow needs. If credentials rotate, update the keychain centrally; Make documents that keys can be managed independently of scenarios and changes apply to modules using that keychain.

Response parsing, redirects, and downstream mapping

Parse response

Parsing is useful when the response is structured and you want to map its fields into later scenario modules. For an HTML page, parsing does not turn the response into a browser-rendered page or execute its scripts. Inspect the actual bundle and response content before designing downstream steps; do not assume that a page’s visible text is available as a ready-made field.

Redirects

The HTTP v4 module can follow redirects when Allow redirects is enabled, up to 10 redirects according to Make’s HTTP app documentation. Check the final status and destination behavior if the protected URL redirects to a sign-in route or a different host. A redirect can mean that authentication was not accepted, that the resource moved, or that the destination expects another login mechanism.

Build the rest of the scenario

1. Run the request once with a known page and inspect the returned status, headers, and body.
2. Decide which response values later modules actually need. Enable parsing when it makes those values mappable.
3. Map the relevant values into downstream modules and handle unsuccessful responses in the scenario’s error-handling path.
4. Keep the credential in its keychain when cloning or reusing the request; check that the destination team or scenario has access to the right credential.

Basic Auth is not the same as a browser login

Basic Auth is an HTTP authentication mechanism. It is different from entering a password into a website’s login form and receiving a session cookie, completing single sign-on, or passing an interactive challenge. Make documents the HTTP module as a request/response tool; its documentation does not say that a basic request runs page JavaScript or completes interactive browser challenges. That distinction follows from the module’s documented behavior.

If the site uses a form login, SSO, session cookies, or another flow, Basic Auth may not be the right authentication type. Make lists Basic Auth, API key, and OAuth 2.0 among its HTTP authentication options; use the method required by the target service. Even when the server accepts the request, client-rendered content may not be present in the HTTP response. A browser-based capture is needed when the task depends on rendering or interactive browser behavior.

Troubleshooting

Symptom	Likely cause	What to check
401 Unauthorized	The credentials are missing, incorrect, or not the pair expected by this endpoint.	Confirm the site’s required username/password values, select the intended keychain, and check whether the endpoint actually uses Basic Auth.
403 Forbidden	The server recognized the request but does not permit access, or another access rule applies.	Check the account’s authorization and the site’s access requirements. Do not assume changing the password will resolve an authorization restriction.
A sign-in page arrives instead of the requested page	The URL redirected, Basic Auth is not the site’s login method, or the destination expects a browser session.	Inspect redirect settings and response behavior. Confirm the authentication flow with the site owner; a form login or SSO flow is not interchangeable with Basic Auth.
Certificate or TLS error	The URL is not HTTPS or the certificate cannot be verified.	Use the correct HTTPS URL with a valid certificate. Make documents that unverified self-signed certificates are rejected.
Response is HTML but expected text or data is missing	The relevant content may be generated by client-side JavaScript, or the response may be a shell page.	Inspect the raw response. If content requires browser execution, an HTTP GET alone does not provide that rendered content.
Later modules have no expected fields	Response parsing is disabled, the response is not in a parseable format, or the field is absent from the server response.	Inspect the module bundle, enable Parse response where appropriate, and map only fields that are actually returned.
Request fails after a redirect	The redirect target may require another authentication method or may be outside the expected destination.	Review whether Allow redirects is enabled, follow the destination, and check the final status and host.

Security, reliability, and cost considerations

• Protect credentials: keep the username and password in Make’s credential keychain. Avoid placing them in query strings, which can be exposed in copied URLs and logs.
• Use HTTPS: Basic Auth’s Base64 representation is not encrypted on its own. HTTPS is necessary for protecting credentials in transit; Make’s HTTP app requires secure HTTPS connections.
• Check permissions and rotation: use the target service’s intended credentials and keep the keychain current when credentials change. Make’s keychain feature centralizes credential management.
• Plan for response variation: authentication expiry, redirects, server errors, and changes to page content can affect later scenario steps. Inspect returned status and content and route failures appropriately.
• Account for what the request does: this HTTP setup retrieves a response; it does not establish browser-rendering behavior. Do not treat a successful HTTP response as proof that a browser-visible page was captured.
• Cost: Make module usage and plan costs depend on the Make plan and scenario execution. The cited setup documentation does not establish a price for this particular workflow; check Make’s current plan details for your account.

Or skip the browser setup

If your goal is a screenshot, ScreenshotNeo is a website screenshot API and MCP server. A one-call request can return an image or PDF for a page the service can access. This example uses a public page; it does not claim to authenticate to a protected page. For an authenticated target, consult the ScreenshotNeo documentation for its supported custom headers, cookies, or Authorization configuration and supply only credentials the target permits.

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

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents use screenshot tools. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Learn more or sign up free for 1,000 screenshots a month, with no card.

FAQ

Can Make retrieve a password-protected webpage?

Yes, when the page accepts HTTP Basic Auth and the request is made to its HTTPS URL with the correct credentials. A successful response may still differ from what a browser displays.

Should I put the username and password in the URL?

No. Use the dedicated Basic Auth credential or keychain field in Make.

Does Parse response render the page?

No. It makes response data available for mapping where parsing applies; it does not run a browser or execute page JavaScript.

What if the protected page requires a form login?

Use the authentication flow the site requires. Basic Auth will not substitute for form-based login, SSO, or an interactive browser session.