DEV Community: clause-netizen

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

Enrich any URL in one request: metadata, tech stack, and a screenshot

clause-netizen — Tue, 16 Jun 2026 13:04:54 +0000

I kept reaching for three separate APIs whenever I needed to enrich a URL: one for link-preview metadata, one to detect a site's tech stack, and one for screenshots. Three keys, three bills, three sets of docs. So I combined them into a single endpoint and put it on RapidAPI. This is a quick walkthrough.

One call, structured output

The core endpoint takes a URL and returns everything it can read from the page and its headers. The landing page exposes this as a no-key live demo, so the example below runs exactly as written — no signup:

curl "https://siteintel.duckdns.org/demo/analyze?url=https://stripe.com"

{
  "query": "https://stripe.com",
  "final_url": "https://stripe.com/en-ca",
  "status": 200,
  "title": "Stripe | Financial Infrastructure to Grow Your Revenue",
  "description": "...",
  "canonical": "https://stripe.com/en-ca",
  "lang": "en-CA",
  "favicon": "https://images.stripeassets.com/.../favicon.svg",
  "open_graph": { "title": "...", "image": "...", "type": "website" },
  "detected_tech": ["Next.js"],
  "social_links": ["https://github.com/stripe", "..."],
  "emails": []
}

You get the metadata and Open Graph tags (the stuff link previews are built from), the favicon, canonical URL, the detected stack, public social profiles, and contact emails when they're listed on the page. The keyed endpoint on RapidAPI (/v1/analyze) returns the same shape.

Screenshots from the same API

The API also renders the page with headless Chromium and returns a PNG via the /v1/screenshot endpoint (with full=true for the entire scrollable page rather than just the viewport). This one runs through your RapidAPI key — the listing page generates a ready-to-run snippet (curl, JS, Python) with the host and key filled in, so grab it there rather than copying a hostname from here.

Why there's no LLM in it

Every field above is deterministic. Metadata lives in <meta> tags. A tech fingerprint comes from script sources, headers, and known markers. Contact links are in the HTML. None of that needs a model, so the response comes back in a few hundred milliseconds and the cost per call stays low. That's the whole reason the pricing can start cheap.

Try it

There's a free tier (50 requests) on RapidAPI, and the landing page runs the real endpoint as a live demo, so you can paste a URL and read the JSON without signing up:

Live demo: https://siteintel.duckdns.org
API + free tier: https://rapidapi.com/hidanny0001/api/siteintel

If you build enrichment, monitoring, or link-preview features, I'd like to hear where the tech detection is wrong or what field you'd want added.