DEV Community: clause-netizen

Detect Any Website's Tech Stack From a Server, No Headless Browser Required

clause-netizen — Tue, 28 Jul 2026 14:00:59 +0000

Wappalyzer's browser extension tells you a site runs Cloudflare and React. That's fine when you're looking at one site in a tab. It falls apart when you have 4,000 domains in a CSV and you want to know which ones run Shopify, or which prospects already have a chat widget installed.

Puppeteer solves it, technically. Then you're maintaining a Chromium install, a memory ceiling, and a job queue for what amounts to reading HTML headers. SiteIntel does the fetch and the fingerprinting server-side and hands you JSON.

One request

curl --get 'https://siteintel.p.rapidapi.com/v1/analyze' \
  --data-urlencode 'url=https://stripe.com' \
  -H 'X-RapidAPI-Key: YOUR_KEY' \
  -H 'X-RapidAPI-Host: siteintel.p.rapidapi.com'

The url param takes a full URL with the scheme. stripe.com won't work, https://stripe.com will. I lost twenty minutes to this before adding a normalizer on my side.

Response:

{
  "query": "https://stripe.com",
  "final_url": "https://stripe.com/",
  "status": 200,
  "fetched_at": "2026-07-28T14:02:11Z",
  "title": "Stripe | Financial Infrastructure to Grow Your Revenue",
  "description": "Stripe powers online and in-person payment processing...",
  "canonical": "https://stripe.com/",
  "lang": "en",
  "favicon": "https://stripe.com/favicon.ico",
  "open_graph": {
    "title": "Stripe | Financial Infrastructure",
    "image": "https://images.stripeassets.com/og.png",
    "site_name": "Stripe",
    "type": "website"
  },
  "detected_tech": ["Cloudflare", "React"],
  "social_links": ["https://twitter.com/stripe", "https://github.com/stripe"],
  "emails": [],
  "server": "nginx"
}

Two things worth knowing about the shape. detected_tech is a flat array of strings, not objects with confidence scores, so you filter it with .includes() and move on. And final_url is the URL after redirects, while query is what you sent. Comparing those two is how you catch domains that silently park on someone else's site.

Node, no dependencies

Global fetch has been stable since Node 18, so this runs as-is:

const HEADERS = {
  'X-RapidAPI-Key': process.env.RAPIDAPI_KEY,
  'X-RapidAPI-Host': 'siteintel.p.rapidapi.com'
};

async function analyze(url) {
  const endpoint = new URL('https://siteintel.p.rapidapi.com/v1/analyze');
  endpoint.searchParams.set('url', url);

  const res = await fetch(endpoint, { headers: HEADERS });
  if (!res.ok) throw new Error(`${url} -> ${res.status}`);
  return res.json();
}

const sites = [
  'https://stripe.com',
  'https://basecamp.com',
  'https://gitlab.com'
];

for (const site of sites) {
  const data = await analyze(site);
  console.log(
    data.final_url.padEnd(32),
    (data.detected_tech ?? []).join(', ') || '(nothing detected)'
  );
}

Note the ?? [] on detected_tech. Sites behind aggressive bot protection return a valid response with very little in it, and a bare .join() on undefined will take down your whole loop on domain 900 of 4,000. Same defensive treatment applies to social_links and emails.

Run the loop serially like that and you'll be waiting a while. In production I run a small concurrency pool of four or five and let failures collect in an array rather than throwing, because one dead domain shouldn't kill the batch.

What I actually built with it

A pre-sales filter. I had a list of ecommerce domains and no interest in pitching the ones already running a competitor's product. The rule ended up being two lines:

const stack = new Set(data.detected_tech ?? []);
const disqualified = stack.has('Shopify') || stack.has('Intercom');

That knocked out roughly a third of the list before anyone wrote a single email. social_links fed a second pass for finding the founder's Twitter, and emails occasionally surfaces a real contact address straight off the homepage, though most sites keep those behind a form.

The same data shape works for a competitive dashboard, tracking when a set of domains migrates off one CDN onto another. You store detected_tech per domain per week and diff it. Migrations show up as a set difference, and you know before the press release does.

Two other endpoints

Same auth, same url param, both useful in the same batch pass:

# on-page SEO report
curl --get 'https://siteintel.p.rapidapi.com/v1/seo-audit' \
  --data-urlencode 'url=https://stripe.com' \
  -H 'X-RapidAPI-Key: YOUR_KEY' \
  -H 'X-RapidAPI-Host: siteintel.p.rapidapi.com'

# screenshot
curl --get 'https://siteintel.p.rapidapi.com/v1/screenshot' \
  --data-urlencode 'url=https://stripe.com' \
  -H 'X-RapidAPI-Key: YOUR_KEY' \
  -H 'X-RapidAPI-Host: siteintel.p.rapidapi.com'

The screenshot endpoint is the one place a browser actually runs, and the point is that it runs on the API's infrastructure instead of yours.

Fair warning on detection

Fingerprinting from HTML and headers catches what a site exposes. Server-rendered frameworks hidden behind a CDN, or anything that only loads after user interaction, won't always show up. If your workflow requires certainty about a single specific site, open it in a browser. If you need a good-enough signal across thousands of them, this is the tradeoff you want.

Working examples and the batch runner: github.com/clause-netizen/siteintel-api. Managed keys on RapidAPI if you'd rather not host anything.

Enrich a CRM lead from nothing but a domain

clause-netizen — Fri, 24 Jul 2026 14:00:45 +0000

A lead comes in with a company website and not much else. You need their tech stack to know if they're worth a demo, their Twitter and LinkedIn for the SDR to reference, and any public contact email so the record isn't a dead end. Doing that by hand takes a few minutes per lead, and it does not scale past about thirty of them.

SiteIntel fetches the page once and returns the parsed result: detected technologies, social profile links, emails published on the page, plus the usual metadata. One request per domain.

The request

Auth is RapidAPI headers. The url param takes a full https:// URL, not a bare domain, which trips people up on the first call.

curl -s "https://siteintel.p.rapidapi.com/v1/analyze?url=https://stripe.com" \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: siteintel.p.rapidapi.com"

Node, using global fetch (18+, no dependencies):

const HOST = "siteintel.p.rapidapi.com";

async function enrich(domain) {
  const url = `https://${HOST}/v1/analyze?url=${encodeURIComponent(`https://${domain}`)}`;
  const res = await fetch(url, {
    headers: {
      "X-RapidAPI-Key": process.env.RAPIDAPI_KEY,
      "X-RapidAPI-Host": HOST,
    },
  });

  if (!res.ok) throw new Error(`${domain}: HTTP ${res.status}`);
  const data = await res.json();

  return {
    company: data.open_graph?.site_name || data.title,
    description: data.description,
    stack: data.detected_tech ?? [],
    socials: data.social_links ?? [],
    emails: data.emails ?? [],
    finalUrl: data.final_url,
  };
}

console.log(await enrich("stripe.com"));

Wrap the loop in a small concurrency limit if you're running a list. Sequential is fine for a few hundred rows overnight; four at a time is plenty for a nightly sync.

Reading the response

{
  "query": "https://stripe.com",
  "final_url": "https://stripe.com/",
  "status": 200,
  "fetched_at": "2026-07-24T14:02:11Z",
  "title": "Stripe | Financial Infrastructure to Grow Your Revenue",
  "description": "Stripe powers online and in-person payment processing...",
  "canonical": "https://stripe.com/",
  "lang": "en",
  "favicon": "https://stripe.com/favicon.ico",
  "open_graph": {
    "title": "Stripe | Financial Infrastructure",
    "image": "https://images.stripecdn.com/...",
    "site_name": "Stripe",
    "type": "website"
  },
  "detected_tech": ["Cloudflare", "React"],
  "social_links": ["https://twitter.com/stripe", "https://www.linkedin.com/company/stripe"],
  "emails": [],
  "server": "nginx"
}

Two things worth knowing before you write your mapping code.

detected_tech and social_links are flat arrays of strings. No nested objects, no confidence scores, no category field. Sorting a social link into a CRM column means matching on the hostname yourself:

const bucket = (links) =>
  Object.fromEntries(
    links.map((u) => {
      const h = new URL(u).hostname.replace(/^www\./, "");
      if (h.includes("linkedin")) return ["linkedin", u];
      if (h.includes("twitter") || h.includes("x.com")) return ["twitter", u];
      if (h.includes("facebook")) return ["facebook", u];
      if (h.includes("instagram")) return ["instagram", u];
      if (h.includes("youtube")) return ["youtube", u];
      return ["other", u];
    })
  );

emails is often empty, and that's the honest answer rather than a guess. It reflects addresses published on the page that was fetched. Plenty of companies route everything through a contact form, so treat a hit as a bonus and never as a required field in your schema.

Also compare final_url against what you sent. A redirect to a different apex domain usually means the company got acquired or rebranded, which is a useful flag on its own.

What to build with it

The thing I actually run: a nightly job that walks CRM records where enriched_at is null, calls /v1/analyze on the website field, and writes back three columns. Stack goes into a tag list, socials into their own fields, and the description becomes the first line of context an SDR sees.

Routing off detected_tech is where it earns its keep. If you sell a Shopify app, a lead whose array contains "Shopify" is a different lead from one running WordPress, and that decision is a single .includes() at ingest time instead of a rep opening a tab. Same trick for scoring: leads on Cloudflare and React skew toward having an actual engineering team, which matters if your product needs one to adopt it.

Cache aggressively. A company's stack does not change between Tuesday and Wednesday, so store the payload and re-fetch monthly. Store the raw JSON alongside your mapped columns too, because the first time you want a field you didn't map, you'll want the original response instead of a re-crawl.

Two other endpoints on the same key are useful in a lead context. GET /v1/seo-audit?url=https://example.com gives an on-page report, which is a decent talking point if you sell anything marketing-adjacent. GET /v1/screenshot?url=https://example.com gets you a thumbnail for the CRM record.

Working examples, including the batch runner: https://github.com/clause-netizen/siteintel-api — it's on RapidAPI too if you'd rather not host anything: https://rapidapi.com/hidanny0001/api/siteintel

Read any URL's title, description, favicon, and OG image with one API call

clause-netizen — Tue, 21 Jul 2026 14:00:38 +0000

Building a link preview means fetching a page, then parsing its <title>, meta description, favicon, and Open Graph tags out of the HTML. Each site nests those in different places, some behind redirects or Cloudflare, and you end up maintaining a small scraper that breaks every few weeks. SiteIntel does the fetch and parse for you and returns the fields as JSON.

One request

The /v1/analyze endpoint takes a full url query param and returns the page's metadata. Here it is with curl:

curl --request GET \
  --url 'https://siteintel.p.rapidapi.com/v1/analyze?url=https://github.com' \
  --header 'X-RapidAPI-Key: YOUR_KEY' \
  --header 'X-RapidAPI-Host: siteintel.p.rapidapi.com'

The url value is the full https:// address, not a bare domain. A trimmed response:

{
  "query": "https://github.com",
  "final_url": "https://github.com/",
  "status": 200,
  "fetched_at": "2026-07-21T14:02:11Z",
  "title": "GitHub · Build and ship software on a single, collaborative platform",
  "description": "Join the world's most widely adopted...",
  "canonical": "https://github.com/",
  "lang": "en",
  "favicon": "https://github.githubassets.com/favicons/favicon.svg",
  "open_graph": {
    "title": "GitHub · Build and ship software",
    "image": "https://github.githubassets.com/assets/campaign-social.png",
    "site_name": "GitHub",
    "type": "object"
  },
  "detected_tech": ["Ruby on Rails", "Fastly"],
  "social_links": ["https://twitter.com/github"],
  "emails": [],
  "server": "GitHub.com"
}

In Node

Global fetch covers this, no dependencies needed:

async function linkPreview(target) {
  const res = await fetch(
    `https://siteintel.p.rapidapi.com/v1/analyze?url=${encodeURIComponent(target)}`,
    {
      headers: {
        'X-RapidAPI-Key': process.env.RAPIDAPI_KEY,
        'X-RapidAPI-Host': 'siteintel.p.rapidapi.com',
      },
    }
  );

  if (!res.ok) throw new Error(`SiteIntel returned ${res.status}`);
  const data = await res.json();

  return {
    title: data.open_graph?.title || data.title,
    description: data.description,
    image: data.open_graph?.image,
    favicon: data.favicon,
    siteName: data.open_graph?.site_name,
    url: data.final_url,
  };
}

console.log(await linkPreview('https://github.com'));

encodeURIComponent matters here since the target URL has its own query string and slashes that would otherwise break your request. The preview object falls back from the Open Graph title to the plain <title> when a page has no OG tags, which is common on older sites.

What the fields give you

The open_graph.image and favicon are what you render in a preview card. final_url is the address after redirects, so store that rather than the URL a user pasted. status tells you whether the fetch actually worked before you trust the rest.

A practical use: a "paste a link" input in a CMS or chat app. On paste, call analyze, and render a card with the OG image, title, and favicon, the way Slack or Discord unfurl links. Because the parsing runs server-side, your frontend never touches the target page or its CORS rules. The detected_tech array (flat strings like "Fastly") and social_links are a bonus if you want to enrich the card or feed a CRM.

Two sibling endpoints exist on the same base if you need them: /v1/seo-audit?url=... for an on-page SEO report and /v1/screenshot?url=... for a rendered image of the page.

Repo with runnable examples: https://github.com/clause-netizen/siteintel-api (also on RapidAPI if you want a managed key).

Turn Any Web Page Into a Print-Ready PDF With One curl Command

clause-netizen — Fri, 17 Jul 2026 14:00:50 +0000

You have a page that renders fine in a browser and now someone wants it as a file: an invoice to attach, a report to archive, a pricing page to snapshot before the next deploy. Wiring up headless Chrome for that means a Puppeteer install, a container with the right shared libraries, and a cold-start problem in CI. For one GET request's worth of work, that stack is overkill.

SnapPDF does the browser part server-side. You send it a URL, it sends back a PDF.

The one-liner

No API key, no headers, no JSON envelope. GET /v1/pdf with a url param returns raw PDF bytes:

curl -G "https://snappdf.dedyn.io/v1/pdf" \
  --data-urlencode "url=https://example.com" \
  -o page.pdf

Use -G with --data-urlencode instead of pasting the target URL into the query string yourself. If the target has its own query params (?id=42&tab=summary), a hand-built URL splits at the first & and you'll render the wrong page. --data-urlencode escapes it for you.

Optional query params, all of which map to what you'd set in a print dialog or a Puppeteer config:

format — paper size, A4 by default
landscape — true or false
background — true or false, controls whether CSS backgrounds print
scale — a number, for shrinking wide layouts onto the page
wait_for_selector — a CSS selector to wait for before rendering

That last one matters most in practice. If the page draws a chart or loads data client-side, render timing decides whether your PDF shows content or a spinner. Point wait_for_selector at an element that only exists once the page is ready:

curl -G "https://snappdf.dedyn.io/v1/pdf" \
  --data-urlencode "url=https://example.com/report?id=42" \
  --data-urlencode "wait_for_selector=#chart-loaded" \
  --data-urlencode "background=true" \
  -o report.pdf

The same thing from Node

Global fetch handles it without any dependencies. Build the URL with URL so encoding stays correct, then write the bytes to disk:

import fs from "node:fs/promises";

const api = new URL("https://snappdf.dedyn.io/v1/pdf");
api.searchParams.set("url", "https://example.com/invoice/42");
api.searchParams.set("wait_for_selector", "#invoice-total");

const res = await fetch(api);
if (!res.ok) throw new Error(`SnapPDF returned ${res.status}`);

const pdf = Buffer.from(await res.arrayBuffer());
await fs.writeFile("invoice.pdf", pdf);

What comes back

The response body is the PDF itself, Content-Type: application/pdf. There is no JSON wrapper, no base64 field to decode, no second request to fetch the result. Pipe it to a file, stream it to S3, or set it as an email attachment as-is. If you want a sanity check in a script, the first bytes of any valid response are %PDF.

That shape is what makes it useful in CI. A GitHub Actions step that archives your live pricing page on every release needs nothing but curl:

- name: Snapshot pricing page
  run: |
    curl -G "https://snappdf.dedyn.io/v1/pdf" \
      --data-urlencode "url=https://yoursite.com/pricing" \
      --fail -o pricing-$(date +%F).pdf

- uses: actions/upload-artifact@v4
  with:
    name: pricing-snapshot
    path: pricing-*.pdf

--fail makes curl exit nonzero on an error status, so a bad render fails the job instead of uploading an HTML error page with a .pdf extension. I run a variant of this that snapshots terms-of-service and pricing pages on a schedule, which turns "what did the page say in March" from an argument into a folder of dated PDFs.

Try it

Examples for other languages and CI setups live in the repo: github.com/clause-netizen/snappdf-api.

Add a "Download as PDF" Button to Any Web App With One GET Request

clause-netizen — Tue, 14 Jul 2026 14:00:42 +0000

Someone on your team asks for a "Download as PDF" button on the invoice page. You look at the options: puppeteer adds a ~300MB Chromium download to your deploy, wkhtmltopdf is abandoned, and the client-side libraries choke on your CSS. All you want is the page you already built, as a PDF.

SnapPDF does that one thing. You give it a URL, it renders the page in a real headless browser, and it returns the PDF bytes. No API key, no JSON envelope, no SDK.

The whole API

GET https://snappdf.dedyn.io/v1/pdf?url=https://EXAMPLE.com

Try it from your terminal:

curl -o example.pdf "https://snappdf.dedyn.io/v1/pdf?url=https://example.com"

Open example.pdf. That's the entire integration.

The response is the raw PDF (Content-Type: application/pdf), not JSON with a base64 blob or a link you have to fetch in a second round trip. Whatever bytes come back, you can write straight to disk or stream straight to a browser.

A few query params when the defaults don't fit:

Param	What it does
`format`	Paper size, `A4` by default
`landscape`	`true` or `false`
`background`	`true` or `false`, render CSS backgrounds
`scale`	Zoom the render, e.g. `0.8` to fit wide tables
`wait_for_selector`	CSS selector to wait for before capture

wait_for_selector is the one that saves you on client-rendered apps. If your invoice page is React and the line items arrive after an API call, pass wait_for_selector=.invoice-total and the capture waits until that element exists instead of snapshotting a spinner.

The download button

Here's the pattern I actually use: an Express route that proxies the PDF, so the browser gets a file download instead of navigating away. Node 18+ has fetch built in, so there are zero dependencies.

app.get("/invoices/:id/pdf", async (req, res) => {
  const pageUrl = `https://yourapp.com/invoices/${req.params.id}`;

  const upstream = await fetch(
    "https://snappdf.dedyn.io/v1/pdf?" +
      new URLSearchParams({
        url: pageUrl,
        wait_for_selector: ".invoice-total",
        background: "true",
      })
  );

  if (!upstream.ok) {
    return res.status(502).send("PDF render failed");
  }

  res.set("Content-Type", "application/pdf");
  res.set(
    "Content-Disposition",
    `attachment; filename="invoice-${req.params.id}.pdf"`
  );
  res.send(Buffer.from(await upstream.arrayBuffer()));
});

The frontend part is an anchor tag:

<a href="/invoices/1042/pdf">Download as PDF</a>

The Content-Disposition: attachment header is what turns a navigation into a download. Skip it and the PDF opens in a tab, which is sometimes what you want for a "Print view" link instead.

Two things worth knowing before you ship this:

The renderer visits the URL like an anonymous browser. If your invoice page sits behind a login, the renderer sees your login screen. Expose the printable view on a tokenized URL (/invoices/1042/print?token=...) that your proxy route generates.
Renders take a couple of seconds since a real browser loads your page. For a button click that's fine. If you're generating hundreds of monthly statements, run it in a queue and cache the output.

Beyond invoices, the same proxy route handles receipts, shipping labels, certificates, and reports. Anything you can build as an HTML page, you can hand to users as a PDF, and HTML plus CSS is a far better layout engine than any PDF library's rectangle-drawing API.

Examples in more languages live in the repo: github.com/clause-netizen/snappdf-api.

Render PDF invoices from an HTML template without putting Chromium in your backend

clause-netizen — Fri, 10 Jul 2026 14:01:31 +0000

You already have an invoice template. It is HTML and CSS, it renders correctly in a browser, and the accountant wants a PDF. So you install Puppeteer, and now your container carries a Chromium build, your serverless bundle blows past the size limit, and you own a font package and a pile of shared libraries you never asked for.

The rendering is not the hard part. Owning the browser is. SnapPDF takes a public URL and hands back PDF bytes, so the browser lives on someone else's box.

One GET, raw bytes back

The whole API surface is a single endpoint:

GET /v1/pdf?url=https://EXAMPLE.com

Point it at the URL where your invoice already renders:

curl -o inv-2043.pdf \
  --get "https://snappdf.dedyn.io/v1/pdf" \
  --data-urlencode "url=https://example.com/invoices/inv-2043" \
  --data-urlencode "format=A4" \
  --data-urlencode "background=true" \
  --data-urlencode "wait_for_selector=#invoice-total"

Use --get with --data-urlencode rather than pasting a query string. Your invoice URL probably carries a signed token, and an unescaped & will silently truncate it.

The optional params: format (A4 by default; A3, A5, Letter, Legal, and Tabloid also work), landscape, background, scale, and wait_for_selector.

From Node, with global fetch

No SDK. Build the URL, read the body as an ArrayBuffer.

import { writeFile } from 'node:fs/promises';

async function renderInvoicePdf(invoiceUrl) {
  const endpoint = new URL('https://snappdf.dedyn.io/v1/pdf');
  endpoint.searchParams.set('url', invoiceUrl);
  endpoint.searchParams.set('format', 'A4');
  endpoint.searchParams.set('background', 'true');
  endpoint.searchParams.set('wait_for_selector', '#invoice-total');

  const res = await fetch(endpoint);

  // Success is application/pdf. Failure is a JSON body with an `error` field.
  if (!res.ok) throw new Error(`snappdf ${res.status}: ${await res.text()}`);

  return Buffer.from(await res.arrayBuffer());
}

const pdf = await renderInvoicePdf('https://example.com/invoices/inv-2043');
await writeFile('inv-2043.pdf', pdf);

console.log(pdf.subarray(0, 5).toString()); // %PDF-

Two things trip people up here. The response is not JSON, so res.json() throws on the happy path. And a 200 with a body that does not start with %PDF- means you rendered someone's login wall, not your invoice.

What the response actually is

Content-Type: application/pdf, and the body is the file. Nothing to unwrap, no base64, no job ID to poll. You can stream it straight to S3, pipe it into a res.send(), or attach it to an email without touching disk.

background=true matters more than it sounds. Chromium drops background colors when printing by default, which turns the colored header row on your line-item table into white on white. Turn it on and your CSS survives.

The thing worth building

Wire it into invoice generation instead of calling it by hand.

When an invoice moves to finalized, mint a short-lived signed URL for the HTML view you already render for the customer, pass that URL to SnapPDF, and write the returned bytes to object storage keyed by invoice ID. The PDF is now a cached artifact, not a render you repeat on every download click. Your template stays one HTML file that designers can edit, and the PDF follows it.

The important detail: your invoice route has to be reachable from the public internet. SnapPDF refuses loopback, private, and link-local addresses, so http://localhost:3000/invoices/1 returns an error rather than a PDF. In development, run a tunnel. In production, a signed URL that expires in sixty seconds is enough.

Rough edges I hit

wait_for_selector is best effort. If the selector never appears, you still get a PDF of whatever managed to load, which is the right behavior for a rendering service and the wrong behavior if you assumed it would fail loudly. Check for your total in the output before you email it to a customer.

scale is clamped to Chromium's own 0.1 to 2.0 range. Values outside that get pulled back in rather than rejected.

Long-polling or websocket-heavy pages take longer than static ones, because the renderer waits for the network to settle before printing. Invoices are static. Dashboards are not.

Working curl and Node examples live at github.com/clause-netizen/snappdf-api if you want to copy something that runs.

How to turn any web page into a PDF with one curl call

clause-netizen — Sat, 04 Jul 2026 14:43:47 +0000

I needed PDF copies of invoice pages for bookkeeping. The usual answer is Puppeteer, which means installing Chromium on your server, keeping it patched, and giving it a few hundred MB of RAM. On a small VPS that hurts. So I put headless Chromium behind a plain HTTP endpoint and now PDF generation is one GET request.

curl --get "https://snappdf.dedyn.io:8444/v1/pdf" \
  --data-urlencode "url=https://en.wikipedia.org/wiki/PDF" \
  --data-urlencode "format=A4" \
  -o page.pdf

That's it. --data-urlencode handles the nested URL for you, and page.pdf comes back as a real Chromium print render, so CSS, web fonts, and layout all survive.

A few query params cover the cases I actually hit:

format for paper size (A4, Letter, and the other common ones)
landscape=true for wide tables
scale from 0.1 to 2 when a page is too cramped or too small at 100%
background=false to drop background colors for cheaper printing
waitForSelector=#invoice-total when the page renders client-side and you need to wait for a specific element before snapshotting

The waitForSelector one matters more than it looks. Most URL-to-PDF converters screenshot React apps before the data loads and you get a PDF of a spinner.

I use it from a cron job that archives receipts, but it works anywhere you can make an HTTP request: a Zapier webhook, a GitHub Action, a fetch() in a route handler.

Code is on GitHub if you'd rather self-host it: https://github.com/clause-netizen/snappdf-api

If you try the demo endpoint and something breaks, tell me. It runs on a small box and I'd like to know where the limits are.

Add Website Screenshots to Your App with a Single GET Request

clause-netizen — Fri, 03 Jul 2026 14:01:00 +0000

You need a thumbnail of a website. Maybe you're building a bookmarking tool, a link-in-bio dashboard, or a portfolio page that shows previews of client sites. Running your own headless Chromium for this means Docker images north of a gigabyte, memory spikes, and a browser process that wedges itself at 3am.

I ship SiteIntel for exactly this. One GET request in, one PNG out. It also does site enrichment and SEO audits from the same base URL, which turns out to be handy once you have screenshots working.

The screenshot endpoint

Auth is standard RapidAPI headers. The url param must be a full https:// URL, not a bare domain.

curl -o shot.png \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: siteintel.p.rapidapi.com" \
  "https://siteintel.p.rapidapi.com/v1/screenshot?url=https://news.ycombinator.com"

That's it. shot.png is a rendered PNG from headless Chromium. Add &full=true if you want the whole page instead of the viewport.

Same thing in Node with global fetch, no dependencies:

const res = await fetch(
  "https://siteintel.p.rapidapi.com/v1/screenshot?url=" +
    encodeURIComponent("https://news.ycombinator.com"),
  {
    headers: {
      "X-RapidAPI-Key": process.env.RAPIDAPI_KEY,
      "X-RapidAPI-Host": "siteintel.p.rapidapi.com",
    },
  }
);

if (!res.ok) throw new Error(`screenshot failed: ${res.status}`);

const buf = Buffer.from(await res.arrayBuffer());
await import("node:fs/promises").then((fs) => fs.writeFile("shot.png", buf));

Note the encodeURIComponent on the target URL. If you skip it, query strings inside the target URL will get eaten by the outer request and you'll spend twenty minutes wondering why example.com/page?id=5 screenshots the homepage.

Pair it with /v1/analyze for real link previews

A screenshot alone gets you a thumbnail. Combine it with the /v1/analyze endpoint and you get everything a rich link preview needs: title, description, favicon, Open Graph data, even detected tech.

curl -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: siteintel.p.rapidapi.com" \
  "https://siteintel.p.rapidapi.com/v1/analyze?url=https://vercel.com"

Response (trimmed):

{
  "query": "https://vercel.com",
  "final_url": "https://vercel.com/",
  "status": 200,
  "title": "Vercel: Build and deploy the best web experiences...",
  "description": "Vercel gives developers the frameworks...",
  "favicon": "https://vercel.com/favicon.ico",
  "open_graph": {
    "title": "Vercel",
    "image": "https://vercel.com/og.png",
    "site_name": "Vercel",
    "type": "website"
  },
  "detected_tech": ["React", "Next.js"],
  "social_links": ["https://twitter.com/vercel"],
  "emails": [],
  "server": "Vercel"
}

The practical build: a bookmark card component. When a user saves a URL, hit /v1/analyze for the title, description, and open_graph.image. If open_graph.image is missing (plenty of sites skip OG tags), fall back to /v1/screenshot and store the PNG yourself. Your cards never render as a bare blue link again, and you wrote zero browser automation.

const meta = await analyze(url); // GET /v1/analyze
const thumb = meta.open_graph?.image ?? (await screenshot(url)); // GET /v1/screenshot fallback

There's also /v1/seo-audit?url=... if you want an on-page SEO report from the same key, same header setup.

Two things worth knowing

Cache the PNGs. Screenshots of the same URL rarely change minute to minute, so store them in S3 or your own disk keyed by URL and re-fetch on a schedule, not on every page load.

Handle failures. A screenshot of a dead or hanging site returns a non-200 with a JSON error body instead of image bytes, so check res.ok before you treat the response as a PNG. The Node example above does this.

Code and more examples: github.com/clause-netizen/siteintel-api — or grab a managed key on RapidAPI.

Fingerprint any website's tech stack from the command line — no Selenium, no headless Chrome

clause-netizen — Tue, 30 Jun 2026 14:00:39 +0000

When you're qualifying leads, auditing competitors, or deciding whether an integration is worth building, the first question is usually "what is this site actually built on?" The browser-based way to answer that — spin up Puppeteer, load the page, sniff window globals and script tags — is slow, memory-hungry, and a pain to run across a list of domains. You just want the server-rendered HTML and headers analyzed, and a clean list back.

That's what /v1/analyze on SiteIntel does: you hand it a URL, it fetches the page server-side, and returns the detected technologies plus the page metadata as JSON.

One request

The API lives at https://siteintel.p.rapidapi.com and authenticates with RapidAPI headers. The url parameter is a full https:// URL, not a bare domain.

curl --request GET \
  --url 'https://siteintel.p.rapidapi.com/v1/analyze?url=https://stripe.com' \
  --header 'X-RapidAPI-Key: YOUR_KEY' \
  --header 'X-RapidAPI-Host: siteintel.p.rapidapi.com'

Same thing in Node, using the global fetch that ships in Node 18+:

const params = new URLSearchParams({ url: "https://stripe.com" });

const res = await fetch(
  `https://siteintel.p.rapidapi.com/v1/analyze?${params}`,
  {
    headers: {
      "X-RapidAPI-Key": process.env.RAPIDAPI_KEY,
      "X-RapidAPI-Host": "siteintel.p.rapidapi.com",
    },
  }
);

const data = await res.json();
console.log(data.detected_tech); // e.g. ["Cloudflare", "React"]

What comes back

The response is a flat object. The fields you'll reach for most:

{
  "query": "https://stripe.com",
  "final_url": "https://stripe.com/",
  "status": 200,
  "fetched_at": "2026-06-30T14:02:11Z",
  "title": "Stripe | Payment Processing Platform",
  "description": "...",
  "canonical": "https://stripe.com/",
  "lang": "en",
  "favicon": "https://stripe.com/favicon.ico",
  "open_graph": {
    "title": "Stripe",
    "image": "https://...",
    "site_name": "Stripe",
    "type": "website"
  },
  "detected_tech": ["Cloudflare", "React"],
  "social_links": ["https://twitter.com/stripe"],
  "emails": [],
  "server": "nginx"
}

Two things worth noting because they save you a parsing step:

detected_tech is a flat array of strings — no nested objects, no confidence scores to dig through. You can .includes("React") directly.
social_links and emails are also flat arrays, pulled from the rendered page, so you get contact surface and tech fingerprint in the same call.

final_url reflects redirects, so if a site bounces http → https or apex → www, you see where it landed. Check status before trusting the rest.

Something to build with it

Point this at a list of domains and you've got a stack-segmented list with no browser in the loop. A small loop that flags every prospect whose detected_tech includes "Shopify", or every site still on a stack you have a migration offer for:

const domains = ["https://a.com", "https://b.com", "https://c.com"];

for (const url of domains) {
  const res = await fetch(
    `https://siteintel.p.rapidapi.com/v1/analyze?url=${encodeURIComponent(url)}`,
    {
      headers: {
        "X-RapidAPI-Key": process.env.RAPIDAPI_KEY,
        "X-RapidAPI-Host": "siteintel.p.rapidapi.com",
      },
    }
  );
  const { final_url, detected_tech, server } = await res.json();
  if (detected_tech.includes("Shopify")) {
    console.log(`${final_url} → Shopify (${server})`);
  }
}

Because each call is a plain HTTP fetch, this runs fine in a serverless function or a cron job — none of the per-domain Chrome startup cost you'd pay doing it client-side.

There are two sibling endpoints on the same base URL when you need more: GET /v1/seo-audit?url=... for an on-page SEO report and GET /v1/screenshot?url=... for a rendered capture.

Working examples and the request snippets are in the repo: https://github.com/clause-netizen/siteintel-api — or grab a managed key on RapidAPI.

Enrich a CRM lead from nothing but its domain

clause-netizen — Sun, 28 Jun 2026 15:56:55 +0000

You get a signup. The form captured one usable field: a work email like dana@northwind.io. Now sales wants to know what this company runs, where to find them, and who to contact. Doing that by hand means opening BuiltWith, scrolling the footer for social links, and grepping the site for a contact address. SiteIntel does the three lookups in one request, so you can run it inside your signup webhook and write the result straight to the CRM.

One request, one URL

You pass a URL. You get back the tech stack, social profiles, and any public emails the site exposes. Here is the curl version against RapidAPI:

curl --request GET \
  --url 'https://siteintel.p.rapidapi.com/v1/analyze?url=https://stripe.com' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  --header 'X-RapidAPI-Host: siteintel.p.rapidapi.com'

The two headers are the auth. X-RapidAPI-Key is your subscription key from the RapidAPI dashboard, and X-RapidAPI-Host has to match the API host exactly or RapidAPI rejects the call before SiteIntel ever sees it. Note the url query param takes a full https:// URL, not a bare domain.

Wiring it into a signup handler

Node 18+ ships fetch globally, so there is no dependency to install. You only have a domain off the email, so turn it into a URL before the call. This function returns a flat object you can map onto CRM fields:

async function enrich(domain) {
  const target = `https://${domain}`;
  const res = await fetch(
    `https://siteintel.p.rapidapi.com/v1/analyze?url=${encodeURIComponent(target)}`,
    {
      headers: {
        'X-RapidAPI-Key': process.env.RAPIDAPI_KEY,
        'X-RapidAPI-Host': 'siteintel.p.rapidapi.com',
      },
    }
  );

  if (!res.ok) {
    throw new Error(`SiteIntel ${res.status}: ${await res.text()}`);
  }

  const data = await res.json();

  return {
    technologies: data.detected_tech ?? [],
    socials: data.social_links ?? [],
    emails: data.emails ?? [],
  };
}

// inside your signup webhook
const domain = email.split('@')[1];
const profile = await enrich(domain);
console.log(profile);

A couple of things worth doing in production: pull the domain with email.split('@')[1] and skip the call when it lands on a freemail host like gmail.com, since there is no company site to read. Check res.ok before parsing, because a 403 from RapidAPI returns a plain-text body, not JSON, and res.json() will throw on it.

Reading the response

The payload returns the page's metadata alongside the three lookups. The fields that matter for enrichment look like this:

{
  "query": "https://stripe.com",
  "final_url": "https://stripe.com/",
  "title": "Stripe | Financial Infrastructure...",
  "detected_tech": ["Cloudflare", "React", "HSTS"],
  "social_links": [
    "https://twitter.com/stripe",
    "https://www.linkedin.com/company/stripe"
  ],
  "emails": ["press@stripe.com"]
}

detected_tech is the array I get the most mileage from. It is a flat list of tech names, so routing questions are a one-line membership check — no separate classifier needed: does the stack include Shopify or WooCommerce, is there a CDN like Cloudflare, did the page advertise a generator. social_links is a deduped list of the social URLs found in the markup, so you can filter it for the network you care about and write the LinkedIn URL straight to a column. emails is only what the site publishes publicly in markup, so treat it as a fallback contact, not a verified inbox.

The practical build: a lead-scoring rule in the signup webhook. If detected_tech includes a known commerce or analytics tool, the company is past the hobby stage, so I tag the lead "qualified" and push it to a sales queue:

const commerce = ['Shopify', 'WooCommerce', 'Magento'];
const qualified = profile.technologies.some(t => commerce.includes(t));

Everything else lands in a nurture list. That decision used to wait on a human opening three tabs. Now it writes itself before the welcome email goes out.

One caveat from running this: a domain with an aggressive bot wall or a fully client-rendered site returns thinner detected_tech and an empty emails array. Default those fields with ?? [] like the code above and your handler keeps moving instead of throwing on a missing key.

Working examples and the webhook wiring are in the repo: https://github.com/clause-netizen/siteintel-api — and it is on RapidAPI if you want a managed key: https://rapidapi.com/hidanny0001/api/siteintel

Detect any website tech stack, metadata, socials & a screenshot — in one API call

clause-netizen — Fri, 26 Jun 2026 16:47:20 +0000

If you've ever needed to know what a website is built with — its framework, its meta tags, the social accounts it links to, plus a screenshot — you've probably reached for three or four different tools to get it. Here's how to get all of it from a single HTTP request.

The problem

Say you're enriching inbound leads, or keeping an eye on a competitor's stack, or doing quick due-diligence on a domain. The data you want is scattered:

Tech stack detection → one tool
Page metadata / OpenGraph → another
Linked social profiles → manual scraping
A screenshot → a headless-browser service

That's a lot of moving parts for "tell me about this URL."

One request instead

SiteIntel bundles it into a single GET. Here's the call through RapidAPI:

curl --request GET \
  --url 'https://siteintel.p.rapidapi.com/v1/analyze?url=https://stripe.com' \
  --header 'X-RapidAPI-Key: YOUR_KEY' \
  --header 'X-RapidAPI-Host: siteintel.p.rapidapi.com'

And the response (this is a real call against stripe.com):

{
  "final_url": "https://stripe.com/en-ca",
  "status": 200,
  "title": "Stripe | Financial Infrastructure to Grow Your Revenue",
  "description": "Stripe is a financial services platform...",
  "lang": "en-CA",
  "favicon": "https://images.stripeassets.com/.../favicon.svg",
  "open_graph": {
    "title": "Stripe | Financial Infrastructure to Grow Your Revenue",
    "image": "https://images.stripeassets.com/.../Stripe.jpg",
    "type": "website"
  },
  "detected_tech": ["Next.js"],
  "social_links": [
    "https://github.com/stripe",
    "https://www.youtube.com/watch?v=eMSqlQMk480"
  ],
  "emails": ["jane.diaz@stripe.com"],
  "server": "nginx"
}

No LLM in the loop, so it's fast and the cost per call stays low.

Using it in code

A small example: take a list of domains and pull the framework + a contact signal for each.

const HEADERS = {
  "X-RapidAPI-Key": process.env.RAPIDAPI_KEY,
  "X-RapidAPI-Host": "siteintel.p.rapidapi.com",
};

async function analyze(url) {
  const res = await fetch(
    `https://siteintel.p.rapidapi.com/v1/analyze?url=${encodeURIComponent(url)}`,
    { headers: HEADERS }
  );
  return res.json();
}

const domains = ["https://stripe.com", "https://vercel.com", "https://figma.com"];

for (const d of domains) {
  const data = await analyze(d);
  console.log(`${d.padEnd(24)} ${data.detected_tech.join(", ") || "—"}`);
}

https://stripe.com       Next.js
https://vercel.com       Next.js
https://figma.com        React

Where this is actually useful

Lead enrichment — turn a raw domain into firmographic-ish signals (stack, socials, a contact email) before it hits your CRM.
Competitor monitoring — diff detected_tech over time to catch a re-platform.
Sales research — "this prospect runs Shopify" changes your pitch.
Content / link previews — open_graph + favicon + a screenshot endpoint (/v1/screenshot) cover preview cards.

Try it without signing up

There's a live demo on the site — paste any URL and watch the JSON come back: siteintel.duckdns.org. When you want it in your own code, the free tier on RapidAPI is 50 requests/month, and Pro is $9.99 for higher throughput.

A couple of honest caveats: tech detection is signal-based, so it finds what's detectable from the markup and headers (it won't see a backend language with no client footprint), and the email field only surfaces addresses already published on the page. For metadata, stack, socials, and screenshots in one call, though, it saves a real amount of plumbing.

If you build something with it, I'd genuinely like to hear what — drop a comment.

Build a link-preview service with one API call

clause-netizen — Thu, 25 Jun 2026 04:24:50 +0000

When someone pastes a URL into your app's comment box or chat, you want to show a preview card: the page title, a short description, the favicon, and the social image. Doing that yourself means fetching the HTML, parsing the <head>, reconciling OpenGraph tags with Twitter cards with bare <meta> tags, chasing redirects, and handling the sites that return garbage. It's a weekend of work and a permanent maintenance tax.

SiteIntel does that parsing for you and hands back clean JSON. One GET request per URL.

The request

The API lives at https://siteintel.p.rapidapi.com and uses RapidAPI's auth headers. Here's a preview for a GitHub repo:

curl --request GET \
  --url 'https://siteintel.p.rapidapi.com/analyze?url=https://github.com/clause-netizen/siteintel-api' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  --header 'X-RapidAPI-Host: siteintel.p.rapidapi.com'

The same thing in Node, using the built-in fetch (Node 18+, no dependencies):

async function getPreview(targetUrl) {
  const endpoint = new URL('https://siteintel.p.rapidapi.com/analyze');
  endpoint.searchParams.set('url', targetUrl);

  const res = await fetch(endpoint, {
    headers: {
      'X-RapidAPI-Key': process.env.RAPIDAPI_KEY,
      'X-RapidAPI-Host': 'siteintel.p.rapidapi.com',
    },
  });

  if (!res.ok) {
    throw new Error(`SiteIntel returned ${res.status}`);
  }
  return res.json();
}

const preview = await getPreview('https://stripe.com');
console.log(preview.title, '—', preview.description);

What you get back

The response gives you the fields a preview card needs, already normalized:

{
  "url": "https://stripe.com",
  "title": "Stripe | Financial Infrastructure to Grow Your Revenue",
  "description": "Stripe powers online and in-person payment processing...",
  "favicon": "https://stripe.com/favicon.ico",
  "ogImage": "https://stripe.com/img/v3/home/social.png"
}

Two things worth knowing from having run this in production. The favicon and ogImage come back as absolute URLs, so you don't have to resolve relative paths against the origin yourself. And description falls back across sources: it prefers the OpenGraph og:description, then the standard meta description, so you usually get something rather than null even on pages that skip OG tags.

One thing to build with it

A comment system that turns pasted links into cards. When a user submits a comment, scan the text for URLs, call the API for each one, and store the result alongside the comment:

async function enrichComment(text) {
  const urls = text.match(/https?:\/\/[^\s]+/g) || [];
  const previews = await Promise.all(
    urls.map((u) => getPreview(u).catch(() => null))
  );
  return { text, previews: previews.filter(Boolean) };
}

The .catch(() => null) matters. Some links will 404 or time out, and you don't want one dead URL to sink the whole comment. Cache previews by URL too, since the same links get pasted over and over and the metadata rarely changes within a day.

That's the whole thing. Fetch, render the card, cache the result.

Working examples and the full field list are in the repo: https://github.com/clause-netizen/siteintel-api. If you'd rather not manage your own scraping infra, it's on RapidAPI with a managed key: https://rapidapi.com/hidanny0001/api/siteintel