Law Change Alerts API: Webhooks for When a Statute or Rule Actually Moves

A law change alerts API watches a specific government source, re-reads it on a schedule, and tells you which individual sections changed since the last read. You get a webhook when a section moves, plus a diff of the old and new text. That is different from a legal news feed, and it is also different from an official announcement that a law takes effect on a date. It is a change in the published text, detected by machine, delivered to your system so a human or an agent can go look.

If your product carries a customer obligation that points at a statute or a rule, this is the piece you cannot build cheaply yourself. Re-reading 4,150,839 sections on a cadence is the whole job.

TL;DR

• A board is one tracked corpus source. It is identified by a corpus type plus a jurisdiction, and jurisdiction is null for federal boards. Each board carries its own refresh cadence.
• Discovery is free. GET /boards lists every watchable source, each row carrying the interval it runs on, the timestamp of its last clean read, and how that read went, so you can build your subscription UI before you spend a credit.
• A change event is a detected difference between two retrievals of the same section. It is a signal to look, not a legal conclusion, and not an effective-date announcement.
• Webhooks fail. Design for it. Push is the latency channel. The changes endpoint is the source of truth. The deliveries endpoint is how you reconcile the two.
• Paused boards are declared, not hidden. The API names every paused source and its reason in its own response, so you find out before you wire an alert to it.
• This is per-section change detection, not point-in-time retrieval. Storage keeps the current text of each citation and nothing older, so there is no as_of=DATE query.

Filed under our legal data infrastructure series.

Everything upstream of the webhook is How We Know a Law Changed. The limit no alert feed gets past is Amendment History and Point-in-Time Law.

The model in one paragraph

A board is one tracked corpus source. A watch is your subscription to a board. A change event is one section on that board whose text differed between two retrievals. A delivery is one attempt to push one change event to your endpoint.

Four nouns. Everything else in this post is what happens between them.

What a board actually is

A board is not a keyword. It is a source we already re-read on a schedule for the corpus itself, exposed as something you can subscribe to. The cadence is not a promise we made to you, it is the cadence the ingestion pipeline already runs at.

Boards are keyed on corpus type plus jurisdiction. CFR has no jurisdiction, because the Code of Federal Regulations is federal. STATE plus tx is the Texas statutory code. REGULATION plus ny is the New York administrative code. A federal board's jurisdiction field is null, and that is the discriminator your code should switch on.

Here are the federal boards and what each one is currently sized at.

State boards follow the same shape across five corpus types: STATE statutory codes for 52 jurisdictions, REGULATION administrative codes for 52, STATE_RULES court rules for 46, STATE_CONSTITUTION for 51, and STATE_AGENCY_GUIDANCE insurance bulletins for 49.

Step 1: list the boards, for free

GET /boards costs nothing. Call it first and cache it, because it is also your health signal.

curl -s https://api.vaquill.ai/api/v1/boards \
  -H "Authorization: Bearer vq_key_..."

Each board comes back with three fields your integration should care about:

• cadence tells you the fastest a change on that board can reach you. Set your customer-facing expectations from this field, not from a marketing page.
• lastRetrievedAt tells you when we last actually read the publisher. If this is stale relative to cadence, something upstream is unhappy.
• retrievalStatus is the board's own verdict on its last cycle.

Page the response. There are more boards than a naive default page size. Request only the first page, render it as "every source we track," and you will quietly hide entire corpora from your users.

Step 2: create a watch

A watch binds a board to a delivery target. In the simplest form that is a corpus type, an optional jurisdiction, and a webhookUrl on your side. The law change alerts reference lists every field a watch accepts.

Scope narrowly. A watch on CFR with no further filter is a watch on 219,114 sections re-read daily. That is reasonable for a regulatory monitoring product and a bad default if you are watching the four rules one customer's obligation depends on. Narrow the watch to the code, title, or chapter you care about and your alert volume becomes reviewable by a human.

Do not make the webhook your only path. Decide this now, because retrofitting reconciliation onto a push-only integration is a rewrite.

Step 3: test it before you trust it

There is a test operation on a watch for one reason: your endpoint will be wrong the first time. Wrong path, wrong auth header, a body parser that rejects the content type, a load balancer that returns 200 before your handler runs.

Fire the test, confirm your handler wrote a row, then go live.

Step 4: read the changes

list_watch_changes gives you the change events on a watch. This is the endpoint you poll, and where your reconciliation loop lives.

Poll it on a schedule that matches the board cadence plus a safety margin. For a daily board, every few hours is plenty. For a weekly board, daily is plenty. The point of the poll is completeness, not latency.

Step 5: get the diff

get_watch_change_diff returns the per-section difference for one change event. That is what makes this useful rather than noisy.

A section-level diff tells you whether the change was a substantive amendment to an exposure limit or an editorial fix to a cross-reference. Without it you are forwarding "something changed in 29 C.F.R. 1910" to a compliance analyst, which teaches them to ignore you.

For any section, watched or not, there is also a section-level change history. If you already know the actId, you can read its change record directly without holding a watch.

Step 6: reconcile with deliveries

list_watch_deliveries is the audit trail of push attempts. It is the endpoint most integrations skip and then wish they had.

Here is the concrete failure it solves. Your webhook handler sits behind a deploy. For 40 minutes it returns 502. A daily board fires during that window. Your system has no row for that change, no error, and no signal that anything is missing, because a webhook that never arrived leaves no evidence on your side.

The fix is a reconciliation job, not better uptime:

1. Every hour, list changes on each watch since your last stored cursor.
2. For anything you have not already processed, process it.
3. When a customer asks "why did I not get alerted about X," list deliveries for that watch and answer with an actual attempt record instead of a shrug.

What a change event is, and what it is not

This is the part that decides whether your product is trusted or embarrassing.

A change event is: the text of one section, retrieved from the government publisher, differing from the text of that same section retrieved on the previous cycle.

A change event is not:

• An official announcement that a law takes effect on a date. Publishers post amendments on their own schedule, sometimes before the effective date, sometimes after.
• A statement that the change is substantive. A typo fix, a renumbered cross-reference, and a re-flowed table all produce a real textual difference.
• A legal conclusion. Nothing in a diff tells you whether your customer's obligation moved.

The right consumer behavior is: a change event is a signal to look. Route it to a diff, apply your own materiality filter, and only then page a human. The four false positive families that make that filter necessary are catalogued in how we know a law changed.

Design notes worth reading before you wire it up

Paused boards

A paused corpus is one that is complete and officially sourced but not currently re-pulling, usually because the publisher's own access rules say so. The freshness array names each one with its reason. A watch on a paused board is a watch on a source nobody is re-reading, so it will never fire, which is why you read that array before you wire an alert.

That is a gap, and we would rather you knew. The freshness array on GET /statutes/coverage declares every pause with its reason, inside the API response itself, so your monitoring can read it rather than a status page.

Court rules gaps

Six jurisdictions have no court rules board, for four different reasons: two publish only an amendment stream with consolidated text behind a commercial licensee, one has no government compilation newer than 2023, two codify their rules into the statute book so they already arrive under the state statutes corpus, and one judiciary does not permit automated access. Each is named with its reason in Legal Data Provenance.

No point-in-time retrieval

Watching a board is forward-only, and so is the corpus behind it: one text per citation, the current one, with no as_of=DATE query to reach an older one. I would rather say that plainly than let you find out in integration.

What does exist: amendment history and a lastAmendedYear on each section, a yearFrom/yearTo currency filter that reads the last amendment year the publisher credits, and per-section diffs on watched boards going forward from the moment you start watching. If your use case is "show me the text as it stood in 2019," this API is the wrong dependency, and Amendment History and Point-in-Time Law sets out the snapshot-and-watch pattern that does work.

Sourcing, because it changes what an alert means

Boards read the government publisher's own site, and a commercial aggregator is never used as a source or as a fallback. Where a state's only consolidated text sits behind a commercial licensee, the corpus carries the gap and declares it.

An aggregator adds its own editorial latency and its own error surface between the legislature and you. If your alert says a rule moved, you want the provenance chain to be one hop, and every result carries the publisher's own source URL so a lawyer can click through and confirm.

The same surface over MCP

Every operation here is also published as an MCP server at mcp.vaquill.ai, using the same vq_key_ credential, and set up in the Vaquill AI MCP integration guide. The tool names map one to one:

That means an agent can hold a watch and reason about its own diffs without you writing an HTTP client. For how that fits a broader agent setup, see our guide on adding legal research to an AI agent over MCP.

A worked integration, end to end

A compliance platform tracks one customer obligation: hazard communication labeling under 29 C.F.R. 1910.1200.

1. Call GET /boards, find the CFR board, read cadence as daily. That is the expectation you set internally.
2. Create a watch scoped to the CFR part the obligation depends on, with webhookUrl pointing at your ingest handler.
3. Fire the test. Confirm a row lands. Ship.
4. On each webhook, fetch the diff and run your materiality rule. Cross-reference renumbering goes to a log. A changed substantive requirement goes to the analyst queue.
5. Hourly, poll changes since your stored cursor and process anything the push missed.
6. Weekly, compare each board's lastRetrievedAt against its cadence. A board that has gone quiet is your upstream alarm, and it fires before a customer notices. That comparison is written out in the coverage monitoring recipe.

Step 6 is the one teams skip. A silent source and a source with no changes look identical from inside your database. Only lastRetrievedAt tells them apart.

Who this is wrong for

• Teams who need historical text. No point-in-time retrieval, so a "what did this say in 2019" product cannot be built on this.
• Teams who want editorial analysis. A diff is raw. A lawyer's summary of what a change means is a different product.
• Teams tracking case law. These boards cover statutes, regulations, court rules, constitutions, session laws, and agency guidance. Primary law, not opinions.
• Teams watching a paused state's statutes. The six paused corpora are not re-pulling, and a watch cannot conjure a retrieval that is not happening.

You can browse the watchable sources and the alert model on the Law Change Alerts page, and check per-jurisdiction currency at the API coverage docs.

FAQ

What is a law change alerts API?

It is an API that re-reads government legal publishers on a schedule and tells you which individual sections changed since the last read. You subscribe to a source, receive a webhook when a section moves, and fetch a per-section diff of the old and new text. It is change detection over primary law, not a news feed.

How is a change event different from an effective date?

A change event means the published text differed between two retrievals. An effective date is a legal fact the publisher or the legislature states separately. A section can change in the published text before, on, or after its effective date, so treat a change event as a prompt to check the effective date, not as the answer.

What happens if my webhook endpoint is down?

You lose the push notification for that event, which is why the changes endpoint exists. Poll it on a cadence that matches the board, process anything you have not seen, and use the deliveries endpoint to see the record of push attempts. An integration built only on webhooks has no way to detect what it missed.

How often do boards refresh?

It depends on the board, because cadence follows the publisher. The CFR and Executive Orders boards refresh daily. Federal Register, Statutes at Large, and federal agency guidance refresh weekly. Federal Rules refresh monthly, Sentencing Guidelines annually. Read cadence from GET /boards rather than hardcoding it.

Can I get the text of a section as it stood on a past date?

Versioning here runs off the amendment record rather than a date parameter. Each citation is stored once, in its current form, and the request takes no as_of parameter to ask for an earlier one. What you get is amendment history per section, a lastAmendedYear, a yearFrom/yearTo currency filter, and per-section diffs going forward from the point you start watching a board.

Does listing boards cost credits?

No. GET /boards is free, along with GET /us/statutes/coverage. Discovery being free is deliberate, because you should be able to build your subscription UI and your monitoring before you commit to spending.

How do I avoid alerting my customers on typo fixes?

Fetch the diff for every change event and apply your own materiality rule before escalating. Editorial fixes, renumbered cross-references, and template re-renders all produce real textual differences. The diff is what separates a substantive amendment from formatting noise.

Which jurisdictions are not covered?

All 50 states plus DC and Puerto Rico are covered for statutes and regulations. Coverage and refresh state vary by corpus, and both are declared per source: the freshness array on the coverage response names every paused corpus with its reason, in the response body.

Is this available over MCP?

Yes. The full board and watch surface is published as an MCP server at mcp.vaquill.ai with the same vq_key_ credential, so an agent can list boards, create watches, and read diffs as tools.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.