sitelyWebsites as typed APIs.

Type-safe data from real websites. URL in, typed object out.

Types follow your imports

Install a site package, hand it to createClient, and your domains, resource names, params, and response shapes are all inferred. No codegen. Typos are compile errors.

Try the client

Refactor without fear

Sites declare their schemas up front. Your IDE knows every field; rename one and every call site lights up. Major-version mismatches surface as 409s before your users see them.

How versioning works

No selectors. No parsers. No CSS debugging.

The site package owns the selectors. You own the call sites. When a layout shifts, that's the package maintainer's problem — not your on-call rotation.

Inside a site package

Schema-checked end to end

Every fresh extraction is validated against its schema before it touches the cache. Bad data never reaches your code; broken extractors surface as `status: "error"`, not silent garbage.

The test suite

Polite by default

robots.txt respected. Per-site rate limits honoured. Adaptive backoff on 429s. Ten parallel calls fan into one upstream fetch. Your IP doesn't get banned because sitely doesn't shotgun.

How the server behaves

Cache and freshness, your call

Hot Redis + cold Postgres, transparent to callers. Pass maxAge=15m when you need recent data; flip acceptStale=false to refuse stale fallback. No global toggles.

Freshness controls

A 30-second look

import { createClient } from "@sitely/client";
import wikipedia from "@sitely/site-wikipedia";

const sitely = createClient({
    baseUrl: "https://sitely.example/api",
    apiKey: process.env.SITELY_API_KEY!,
    sites: [wikipedia],
});

const article = await sitely
    .site("en.wikipedia.org")
    .resource("article", { title: "TypeScript" });

console.log(article.data.headline);    // "TypeScript"
console.log(article.data.categories);  // ["Programming languages", …]

The site, the resource, the params, and the response shape are all typed against the imported @sitely/site-wikipedia. Drop a package, drop the inference along with it.

The same call from anywhere else, via the HTTP API:

bash

curl "https://sitely.example/api/v1/sites/en.wikipedia.org/article?title=TypeScript" \
    -H "Authorization: Bearer sitely_sk_..."

The client adds inference, retries, pagination, and cancellation. The HTTP API is the contract underneath.

What you get

One npm package per site. Each site package declares typed resources (article, product, recipe). Schemas can compose schema.org types or be fully custom — interop where useful, no ceiling.
No fallback path; no surprise shapes. Every response comes from a typed site package. URLs whose hostname isn't covered return a clean error, not a best-effort guess.
Caching with sensible defaults. Hot Redis + cold Postgres, per-resource TTL, consumer-side max-age control, stale data as a fallback when extraction fails (opt-out via acceptStale: false).
Request coalescing. Ten parallel calls to the same URL trigger one extraction.
Rate limits on your behalf. Per-key for fairness; per-site for politeness; surfaced as 429 with Retry-After.
robots.txt respected by default. No flag overrides it on the server path.
Deterministic builds. Site packages compile reproducibly; the published manifest is byte-identical to a clean rebuild, signed-friendly, and diffable across versions.

Where to start

You want to…	Start here
Call sitely from TypeScript	Using the client
Call sitely from any language	Consuming the HTTP API
Run sitely on your own infrastructure	Self-hosting the server
Add a new site	Writing a site package
Understand the architecture	Architecture overview