Remulous LabsLayoffLens › API vs. scraping

Guide · WARN data

How to get WARN Act layoff data

There are two practical ways to build a national view of US WARN Act layoff and plant-closure notices: scrape each state agency portal yourself, or call one normalized API. This page compares them honestly so you can pick the right one.

Short answer

The raw WARN notices are public records, so scraping is viable if you only need one or two states and don't mind maintaining parsers. The moment you need a national, consistently-formatted, kept-current view, the per-state maintenance cost outweighs the build, and a normalized API like LayoffLens is the cheaper path. The dividing line is coverage breadth and how often you need the data fresh.

Why WARN data is fragmented

The WARN Act is federal, but it is administered by the states.

Employers file their notice with the state where the layoff happens, not with a single federal registry. So each state's labor or workforce agency publishes its own notices, in its own format, on its own schedule. In practice that means:

No shared schema

One state publishes an Excel file, another an HTML table, another a PDF or a dashboard export. Column names, date formats, and how "employees affected" is recorded all differ.

No shared schedule

Some states update weekly, some monthly, some sporadically. There is no national "new notices today" feed — you have to poll each source independently.

Layouts change without notice

An agency redesigns a page or shifts a spreadsheet column and your scraper silently breaks. Each state is a separate thing that can fail.

Uneven history & quality

Coverage depth varies — most states publish a rolling current + prior year, a few carry deep archives, and filings can contain amendments, duplicates, or late entries.

Side by side

Scraping state portals yourself vs. calling the LayoffLens API.

 Scrape it yourselfLayoffLens API
CoverageOne scraper per state you need; national coverage = ~30 separate builds.29 states + DC behind one endpoint.
FormatHTML / PDF / Excel — different per state, normalize yourself.One JSON schema across every state.
FreshnessYou schedule and run polling per source.Daily ingest; per-state freshness via /v1/states/{state}/status.
MaintenanceOngoing — layouts change and break parsers.Handled for you.
QueryingBuild your own filtering/storage.Filter by state, employer, date, min_affected in the request.
ProvenanceYou track which source each row came from.Every record carries source_url to the official filing.
Upfront costHigh engineering time before any data flows.Minutes — get a key and query.
Best whenYou need 1–2 states, or fully custom parsing.You need a national, current, consistent view.

What the API call looks like

Everything above — coverage, normalization, freshness, provenance — collapses into one request.

Texas notices affecting 100+ employees, newest first

curl -X GET "https://layofflens-warn-data-api.p.rapidapi.com/v1/notices?state=TX&min_affected=100&limit=2" \
  -H "X-RapidAPI-Key: YOUR_KEY_HERE" \
  -H "X-RapidAPI-Host: layofflens-warn-data-api.p.rapidapi.com"

See the full request examples (cURL, JavaScript, Python) and the OpenAPI spec ↗ on the LayoffLens page.

Frequently asked questions

Where does WARN Act layoff data come from?

There is no single federal source for WARN notices. The WARN Act requires employers to notify the state where the layoff occurs, so each state's labor or workforce agency publishes its own notices independently — as HTML tables, PDFs, Excel files, or dashboards, each with its own schema and update schedule. To assemble a national picture you must collect from every state separately.

Can I scrape WARN notices from state websites myself?

Yes, the underlying notices are public records. But there is no shared format: you would build and maintain a separate scraper or parser for each state, normalize inconsistent column names and date formats, handle layouts that change without notice, and re-run everything on each state's own schedule. It is feasible but becomes an ongoing maintenance burden rather than a one-time build.

What is the advantage of a WARN data API over scraping?

A WARN data API like LayoffLens collapses 28 separate sources into one normalized schema with one authentication scheme and one set of query parameters. Coverage, ingestion freshness, and parser maintenance are handled for you, and every record carries a source_url back to the original state filing so you can verify provenance. You query by state, employer, date, or layoff size instead of writing per-state parsers.

How many states publish WARN data?

Most states publish some WARN data, but formats and reliability vary widely. LayoffLens currently normalizes 29 states plus Washington DC — the jurisdictions whose agencies publish data that can be reliably parsed and kept current. The covered-state list is returned by GET /v1/meta.

Skip the 28 scrapers

Free tier on RapidAPI — no credit card to start. One normalized API for national WARN coverage, with provenance on every record.