DEV Community: clause-netizen

Build a link-preview card from any URL with one API call

clause-netizen — Fri, 14 Aug 2026 14:01:04 +0000

Someone pastes a link into your comment box and you want to render the card Slack renders: title, description, favicon, preview image. Building that yourself means fetching the page, following redirects, parsing <meta> tags, resolving relative image paths against the final URL, and handling the third of the web that ships no OG tags. You end up maintaining a scraper.

SiteIntel does that fetch-and-parse in one GET. Here's the whole thing.

The 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"

The url param takes a full URL with the scheme, not a bare domain. URL-encode it if the target has its own query string, or you'll lose everything after the first &.

You get back:

{
  "query": "https://stripe.com",
  "final_url": "https://stripe.com/",
  "status": 200,
  "fetched_at": "2026-08-14T15:02:11.418Z",
  "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 to Grow Your Revenue",
    "image": "https://images.stripecdn.com/...og.png",
    "site_name": "Stripe",
    "type": "website"
  },
  "detected_tech": ["Cloudflare", "React"],
  "social_links": ["https://twitter.com/stripe"],
  "emails": [],
  "server": "nginx"
}

In Node

Node 18+ has fetch globally, so there's no dependency to install.

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

async function analyze(url) {
  const endpoint = `https://${HOST}/v1/analyze?url=${encodeURIComponent(url)}`;
  const res = await fetch(endpoint, {
    headers: {
      'X-RapidAPI-Key': process.env.RAPIDAPI_KEY,
      'X-RapidAPI-Host': HOST,
    },
  });
  if (!res.ok) throw new Error(`SiteIntel returned ${res.status}`);
  return res.json();
}

function toCard(data) {
  const og = data.open_graph || {};
  return {
    url: data.final_url,
    title: og.title || data.title || data.final_url,
    description: data.description || '',
    image: og.image || null,
    icon: data.favicon,
    site: og.site_name || new URL(data.final_url).hostname,
  };
}

const data = await analyze('https://stripe.com');
console.log(toCard(data));

The fallback chain in toCard is the part that matters. Plenty of pages set <title> but no og:title, or the reverse. Any of these fields can come back null when the page never declared them, so read them defensively rather than assuming a full house.

Reading the response

query is what you sent; final_url is where you landed after redirects. Key your cache on final_url, not query, or you'll store four copies of the same article behind four different tracking URLs. status is the HTTP status of the target page, so a 200 from the API with a status of 404 means the fetch worked and the page is gone. Don't render a card for that.

favicon and open_graph.image come back as absolute URLs, already resolved against the final URL. That's the piece that eats an afternoon when you write the parser yourself.

Two fields are flat arrays of strings, not objects: detected_tech is ["Cloudflare", "React"], and social_links is a list of URLs. If you're mapping over them, you're mapping over strings.

What I'd build with it

A preview cache. When a user submits a link, call /v1/analyze once, run toCard, and store the result as a row next to the comment with the fetched_at timestamp. Render from your own database from then on. The user's page load never waits on a third-party fetch, and a slow or dead target site degrades to a plain link instead of hanging your request.

Two things fall out of that design. Refresh a row when fetched_at gets older than your TTL, seven days works fine for article metadata. And when open_graph.image comes back null, fall back to GET /v1/screenshot?url=... for that URL and store the screenshot as the card image. Sites without OG tags still get a picture.

There's also GET /v1/seo-audit?url=... on the same base URL if you want an on-page report rather than a preview.

Working examples and the full response fields: github.com/clause-netizen/siteintel-api. It's on RapidAPI if you want a managed key.

Turn any URL into a print-ready PDF with one GET request

clause-netizen — Tue, 11 Aug 2026 14:01:29 +0000

You need a PDF of a page your app already renders: an invoice, a monthly report, a receipt. The usual path is bundling headless Chromium into your build image, which adds a few hundred megabytes of system libraries, a --no-sandbox flag someone will question in code review, and a Dockerfile that breaks the next time the base image moves. The older alternative, wkhtmltopdf, froze on an ancient WebKit, so anything using grid or modern flexbox comes out looking wrong.

SnapPDF is one GET request that returns the PDF bytes. No API key on the direct base URL, no job queue, no polling.

The request

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

If your target URL has its own query string, let curl encode it instead of hand-escaping ampersands:

curl -fsS -o report.pdf --get \
  --data-urlencode "url=https://example.com/reports/q3?theme=print" \
  --data-urlencode "format=Letter" \
  --data-urlencode "landscape=true" \
  --data-urlencode "wait_for_selector=#totals" \
  https://snappdf.dedyn.io/v1/pdf

The optional params:

Param	Values	Notes
`format`	`A4` (default), `A3`, `A5`, `Letter`, `Legal`, `Tabloid`	Page size
`landscape`	`true` \	`false`
`background`	`true` \	`false`
`scale`	number, 0.1–2	Chromium's own print scale range
`wait_for_selector`	CSS selector	Waits for that element before printing

wait_for_selector is the one that saves you. The renderer waits for the network to go idle, but a client-rendered dashboard often settles its requests a beat before it paints the numbers. Point the selector at something that only exists after your data lands and you stop shipping PDFs of a loading spinner.

The response

The body is the raw PDF, served as Content-Type: application/pdf. It is not JSON, and there is no base64 wrapper or data key to unwrap. Read it as bytes and write it to disk.

Errors are the exception: a bad or unsupported request comes back as 400 and a failed render as 502, both JSON with error and detail keys. So branch on the status code before you touch the body.

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

const params = new URLSearchParams({
  url: 'https://example.com/invoices/1042',
  format: 'A4',
  background: 'true',
  wait_for_selector: '#invoice-total',
});

const res = await fetch(`https://snappdf.dedyn.io/v1/pdf?${params}`);

if (!res.ok) {
  const { error, detail } = await res.json();
  throw new Error(`${error}: ${detail}`);
}

const pdf = Buffer.from(await res.arrayBuffer());
await writeFile('invoice-1042.pdf', pdf);

That Buffer.from(await res.arrayBuffer()) matters. Calling res.text() on a PDF corrupts it, since the bytes are not valid UTF-8 and the decoder replaces what it cannot map.

Wiring it into CI

The version I actually use runs on a docs repo. Every merge to main, the job re-renders the published pages and uploads them as a build artifact, so support can hand a customer the exact doc set that shipped with a release:

- name: Render docs to PDF
  run: |
    mkdir -p pdfs
    while read -r slug; do
      curl -fsS --get --retry 3 \
        --data-urlencode "url=https://docs.example.com/$slug" \
        --data-urlencode "wait_for_selector=article" \
        -o "pdfs/$slug.pdf" \
        https://snappdf.dedyn.io/v1/pdf
    done < docs-pages.txt

- uses: actions/upload-artifact@v4
  with:
    name: docs-pdf
    path: pdfs/

Keep the -f on curl. Without it curl exits 0 on a 502 and happily writes the JSON error body into a file named .pdf, and you find out weeks later when someone opens it. With -f the step fails where the problem happened.

The same loop works for invoices keyed off order IDs, or for a nightly snapshot of an internal dashboard mailed to whoever asked for it.

Working curl, Node, and Python examples live in the repo: github.com/clause-netizen/snappdf-api

Add a "Download as PDF" button with one GET request

clause-netizen — Fri, 07 Aug 2026 14:01:44 +0000

A teammate asks for a PDF export of the invoice page you already built. The client-side route (html2canvas plus jsPDF) hands back a fuzzy raster of the viewport with your CSS grid collapsed. The server-side route means adding Playwright to your image, a Chromium download, and enough memory headroom to run it.

SnapPDF runs the headless browser somewhere else and returns the bytes. It's a plain GET: no SDK, no auth headers on the direct base URL.

One request

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

If your target URL carries its own query string, encode it. Otherwise its params bleed into SnapPDF's:

curl -G "https://snappdf.dedyn.io/v1/pdf" \
  --data-urlencode "url=https://example.com/invoice?id=8814&t=abc" \
  --data-urlencode "format=Letter" \
  -o invoice.pdf

Wiring it to a button

Node 18+ ships fetch globally. Proxy the call through your own server so you control the filename and never expose the target URL to the client:

// GET /invoices/:id/pdf
app.get("/invoices/:id/pdf", async (req, res) => {
  const target = `https://app.example.com/invoices/${req.params.id}?print=1`;

  const api = new URL("https://snappdf.dedyn.io/v1/pdf");
  api.searchParams.set("url", target);
  api.searchParams.set("format", "Letter");
  api.searchParams.set("background", "true");
  api.searchParams.set("wait_for_selector", "#invoice-total");

  const r = await fetch(api);

  if (!r.ok) {
    console.error("snappdf failed", r.status, await r.text());
    return res.status(502).json({ error: "pdf_failed" });
  }

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

The front end becomes <a href="/invoices/8814/pdf">Download PDF</a>. No blob URLs, no client JS at all.

What comes back

The body is raw PDF bytes with Content-Type: application/pdf. No base64, no JSON wrapper on success, nothing to parse. Don't call r.json() on it.

Two behaviors to plan around:

The API sets Content-Disposition: inline, so a link straight to the endpoint opens the browser's PDF viewer instead of downloading. Overriding that header in your proxy (as above) is what turns it into a download.

Failures come back as JSON with a non-2xx status, so branch on r.ok before you trust the bytes. A URL you can't reach or can't parse returns an error status, not a broken PDF.

The params worth knowing

format — A4 by default. A3, A5, Letter, Legal, Tabloid also work.
background — true by default. Set false to drop background colors and images for a printer-friendly copy.
landscape — true or false.
scale — a number. Shrinking to 0.8 pulls a wide table back onto one page.
wait_for_selector — a CSS selector the renderer waits for before printing. This is the one that earns its keep on SPAs and charts: point it at an element that only exists after the data lands, and you stop shipping PDFs of your loading skeleton.

What I'd build with it

The setup that's worked for me: a print-only route plus a signed link.

Give the report page a ?print=1 mode that hides the nav, sidebar, and cookie banner, then widens the content to the page width. Mint a short-lived signed URL for that route and pass it as url=. The renderer arrives as an anonymous browser from outside your network, so it has no session cookie; the signature in the URL is how the page authorizes it.

Once that route exists, "email me a monthly statement" is a cron job with three steps: render, attach, send.

One constraint to design around: the renderer refuses localhost and private IP ranges, which is the SSRF guard doing its job. Your page has to be reachable from the public internet. In development, tunnel it with ngrok or cloudflared, or point at a deploy preview.

Examples and the OpenAPI spec live here: github.com/clause-netizen/snappdf-api

Render invoices to PDF with a GET request instead of shipping Chromium

clause-netizen — Tue, 04 Aug 2026 14:01:05 +0000

Every "generate a PDF invoice" ticket ends the same way: you already have the invoice as an HTML template that looks right in the browser, and now you need bytes you can email or store. The usual answer is Puppeteer, which drags a ~300MB Chromium download into your image, needs a pile of shared libraries on slim base images, and falls over on the first serverless deploy that has a 250MB bundle limit. The alternative is rewriting your invoice layout in a PDF drawing library, which means maintaining the same document twice.

A hosted renderer sidesteps both. You keep the HTML template, and the PDF is one HTTP GET.

One request

SnapPDF takes a public URL and returns PDF bytes:

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

No headers, no auth dance on the direct base URL, no JSON envelope to unwrap. The response body is the PDF.

Query params, all optional:

Param	Values	Default
`format`	`A4`, `Letter`, etc.	`A4`
`landscape`	`true` / `false`	`false`
`background`	`true` / `false`	`true`
`scale`	number	`1`
`wait_for_selector`	CSS selector	none

background matters more than it sounds for invoices. Chromium drops CSS backgrounds when printing by default, so your header bar and zebra-striped line items vanish unless it's on.

wait_for_selector is the one that saves you. If your invoice template fetches line items client-side, the renderer will otherwise happily print an empty table. Have the template set something like <div id="invoice-ready"> once totals are painted, and point the param at #invoice-ready.

curl -o invoice.pdf \
  "https://snappdf.dedyn.io/v1/pdf?url=https%3A%2F%2Fexample.com&format=Letter&background=true&wait_for_selector=%23invoice-ready"

Node, with global fetch

Node 18+ has fetch built in, so there's no dependency at all:

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

async function renderPdf(targetUrl, opts = {}) {
  const qs = new URLSearchParams({ url: targetUrl, ...opts });
  const res = await fetch(`https://snappdf.dedyn.io/v1/pdf?${qs}`);

  if (!res.ok) {
    throw new Error(`SnapPDF ${res.status}: ${await res.text()}`);
  }
  const type = res.headers.get("content-type") || "";
  if (!type.includes("application/pdf")) {
    throw new Error(`Expected a PDF, got ${type}`);
  }
  return Buffer.from(await res.arrayBuffer());
}

const pdf = await renderPdf("https://example.com", {
  format: "Letter",
  background: "true",
});
await writeFile("invoice.pdf", pdf);

URLSearchParams handles the encoding, which you want — invoice URLs usually carry a token, and an unencoded & in there silently truncates the target.

The content-type check isn't paranoia. Any failure path that returns a JSON error will otherwise get written to disk as invoice.pdf, and you'll find out when a customer opens it.

What you actually get back

A 200 with Content-Type: application/pdf and the raw file in the body. Nothing to parse, nothing to base64-decode. Treat it as a Buffer (or a stream) and hand it to whatever comes next: S3, a Nodemailer attachment, res.send().

The one constraint worth planning around: the renderer fetches the URL over the public internet, so localhost:3000/invoices/1042 won't work and neither will a page behind your session cookie. The pattern that does work is a signed, short-lived, unauthenticated route.

The thing I'd build with it

An /invoices/:id/pdf endpoint that reuses the template you already have:

import express from "express";
import crypto from "node:crypto";

const app = express();

// Public, signed, no session required — this is what the renderer loads.
app.get("/render/invoice/:id", (req, res) => {
  if (!validSignature(req.params.id, req.query.sig)) return res.sendStatus(403);
  res.send(renderInvoiceHtml(req.params.id)); // your existing template
});

app.get("/invoices/:id/pdf", requireAuth, async (req, res) => {
  const { id } = req.params;
  const sig = crypto
    .createHmac("sha256", process.env.RENDER_SECRET)
    .update(id)
    .digest("hex");

  const target = `https://yourapp.com/render/invoice/${id}?sig=${sig}`;
  const pdf = await renderPdf(target, {
    format: "Letter",
    background: "true",
    wait_for_selector: "#invoice-ready",
  });

  res.type("application/pdf")
     .set("Content-Disposition", `attachment; filename="invoice-${id}.pdf"`)
     .send(pdf);
});

Two routes, one template, zero browser binaries. The HTML invoice stays the source of truth — when finance asks for the tax line to move, you edit CSS and both the web view and the PDF change together.

Same shape works for packing slips, signed quotes, and monthly reports. Anything where you already built the HTML and someone downstream wants a file.

Working examples and the full param list: github.com/clause-netizen/snappdf-api

Add website screenshots to your app with a single GET request

clause-netizen — Fri, 31 Jul 2026 14:00:40 +0000

You need a thumbnail of a user-submitted URL. Maybe it's a link preview in a dashboard, a visual record attached to a saved bookmark, or a proof-of-state image in an audit log. The usual answer is to install Playwright, ship Chromium into your container, and then own a headless browser in production forever.

SiteIntel does that part for you. One GET, PNG bytes back.

The request

/v1/screenshot takes a full https:// URL (not a bare domain) and responds with image/png:

curl -s -X GET \
  'https://siteintel.p.rapidapi.com/v1/screenshot?url=https://stripe.com' \
  -H 'X-RapidAPI-Key: YOUR_KEY' \
  -H 'X-RapidAPI-Host: siteintel.p.rapidapi.com' \
  --output stripe.png

That's the whole integration. The response body is the image, so pipe it to a file, an S3 upload, or straight through to your own res.

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

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

async function screenshot(url) {
  const res = await fetch(`${API}/v1/screenshot?url=${encodeURIComponent(url)}`, { headers });
  if (!res.ok) throw new Error(`screenshot failed: ${res.status}`);
  return Buffer.from(await res.arrayBuffer()); // PNG bytes
}

const png = await screenshot('https://stripe.com');
await fs.promises.writeFile('stripe.png', png);

Two things worth knowing. encodeURIComponent matters here: the target URL has its own ? and &, and skipping the encode is the most common way this call silently grabs the wrong page. And on failure the API returns JSON instead of PNG, so check res.ok before you treat the body as an image.

The metadata that goes with it

A screenshot alone is a picture with no text. /v1/analyze fills in what the page actually is:

async function analyze(url) {
  const res = await fetch(`${API}/v1/analyze?url=${encodeURIComponent(url)}`, { headers });
  if (!res.ok) throw new Error(`analyze failed: ${res.status}`);
  return res.json();
}

const site = await analyze('https://stripe.com');
console.log(site.title, site.detected_tech);

The shape:

{
  "query": "https://stripe.com",
  "final_url": "https://stripe.com/",
  "status": 200,
  "fetched_at": "2026-07-31T14: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"],
  "emails": [],
  "server": "nginx"
}

detected_tech and social_links are flat arrays of strings, so no unwrapping objects to get at a name. final_url is what you actually landed on after redirects, which is the field you want to store as the canonical record rather than whatever the user typed. status is the target site's status code, not the API's; a 200 from SiteIntel carrying "status": 404 means the request worked and the page is gone.

One thing to build with it

A link-preview card that doesn't depend on the site having good Open Graph tags. Call /v1/analyze first, use open_graph.image when it's there, and fall back to /v1/screenshot when it isn't:

async function preview(url) {
  const site = await analyze(url);
  return {
    url: site.final_url,
    title: site.title,
    description: site.description,
    favicon: site.favicon,
    image: site.open_graph?.image || null, // else render the screenshot endpoint
  };
}

If image comes back null, point your <img> at your own proxy route that pipes the screenshot bytes through. Cache the PNG keyed on final_url and store fetched_at alongside it so you know when to refresh. Most pages don't change often enough to justify a fresh capture on every render.

For the SEO side of the same site, /v1/seo-audit?url=https://example.com returns an on-page report, which pairs well if you're building anything that grades or monitors URLs rather than just displaying them.

Working examples live in the repo: github.com/clause-netizen/siteintel-api — it's also on RapidAPI if you want a managed key.

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.