Custom HTTP Headers: Forward any header, keep secrets safe
Stop scraping the logged-out version. Public values go in headers; secrets ride as x-api-header-* request headers and never touch the URL.
Microlink strips the x-api-header- prefix on the way out — the credential never lands in a URL.
Forward any HTTP header to the target page — Accept-Language, User-Agent, Cookie, Authorization, or any custom value. Same pattern across every Microlink output.
Two channels: headers for non-sensitive values that are safe in the URL; x-api-header-* for cookies, tokens, and other secrets — Microlink strips the prefix and forwards the original header to the target without ever logging the value into the public query string.
That's everything you need to reach logged-in dashboards, localized variants, A/B test cohorts, basic-auth staging environments, or any header-shaped page variant — without leaking credentials.
Public values stay public, secrets stay private
The split exists for one reason: query strings are publicly visible — in browser history, in server logs, in URL embeds — while HTTPS request headers are not. Pick the channel that matches the sensitivity of the value, and Microlink does the right thing on the way out.
headers as a JSON object on the MQL request: locale, user-agent, referer, custom headers — anything safe to put in a public URL. Microlink applies them verbatim when fetching the target.x-api-header-. Microlink strips the prefix and forwards the original header to the target.Recommended: server-side, secrets in process env
Public values go in the second argument (headers); private ones go in MQL's third argument (httpOptions.headers) prefixed with x-api-header-. Both reach the target page; only secrets stay off the URL.
import mql from '@microlink/mql'
const { data } = await mql(
'https://example.com/dashboard',
{
screenshot: true,
meta: false,
headers: {
'accept-language': 'es-ES'
}
},
{
headers: {
'x-api-key': process.env.MICROLINK_API_KEY,
'x-api-header-cookie': `session=${process.env.SESSION_COOKIE}`,
'x-api-header-authorization': `Bearer ${process.env.AUTH_TOKEN}`
}
}
)Public values, private secrets.
Pick the volume that matches your traffic. Custom HTTP headers — both headers and x-api-header-* — are included on every Pro plan, across every workflow.
What is the difference between headers and x-api-header-*?
headers parameter goes through the URL query string and is publicly visible — fine for locale, user-agent, or referer.x-api-header-* pattern is sent as a request header on the Microlink call itself, so cookies, bearer tokens, basic-auth values, and any other secret never appear in the URL or in logs. Microlink strips the x-api-header- prefix and forwards the original header name to the target.Can I forward cookies and authorization tokens?
x-api-header-* only. Send x-api-header-cookie or x-api-header-authorization as request headers on your Microlink call; Microlink forwards the original cookie or authorization header to the target.headers parameter would leak them via the URL, so the API treats x-api-header-* as the safe path for any credential.Does this work for screenshots and PDFs too?
headers and x-api-header-* apply uniformly to screenshots, PDFs, metadata, HTML, markdown, insights, and data extraction.How do I keep API keys out of client-side code?
httpOptions) to pass x-api-key and any x-api-header-* values from environment variables.What if the target also blocks headless browsers?
x-api-header-cookie and combine with the proxy parameter (or the automatic proxy resolution included in Pro).EPROXYNEEDED, the target requires a proxy-backed request.Do headers and x-api-header-* work on free plans?
headers parameter is rejected, and x-api-header-* values are ignored.