Webhook event types

A webhook watches a saved view — or the whole organization — and tells you when something in it changes. Choose the events when you create it; every new webhook starts with the nightly digest and the two events that warn you when data is late or coverage changes, so a quiet feed is never mistaken for a quiet legislature.

Events#

Amendments#

An amendment is adopted or fails is sent when CapitolMath records a legislature's decision on an amendment to a bill the webhook watches: adopted, or not adopted. It's sent once, within a week of the action that decided it, and only where the amendment's record names that action. If the legislature corrects that action and the outcome stays the same, it isn't sent again. At most 20 decisions on one bill are sent from one update; the rest aren't sent. A committee's recommendation isn't an adoption, so it's never sent as one. Amendments CapitolMath records from a bill's earlier history are never sent. If amendments are turned off, a webhook that has the event keeps it and receives nothing until they're back.

Our tracking#

Three events come from your team's own work rather than the legislature's: Our position on a bill changes, A tracked bill gets a new owner and A note is added to a tracked bill. They're sent a minute or so after the change, not after the nightly update. Tracking a bill counts as a change from nothing: tracked with a position, it sends the position; tracked by anyone, it sends its first owner.

A webhook acts with its owner's access, so it sends only what the person who owns it can see in CapitolMath:

• Only their tracked bills. A bill tracked for a client walled off from them never reaches their webhook, and neither does an archived client's work. If their access is narrowed or they leave the organization, it stops at once, for anything still waiting to be sent too.
• A client they can't see is unnamed. The event says Another client instead.
• No position while positions are off for the organization.
• A note's id and author, never its text. Read the note in CapitolMath. Only someone who can read the bill's notes gets the event.
• Never a file or a custom field. Attachments and custom field values aren't in any webhook.

They need access to Tracked items: the builder offers them only to members who have it. A webhook on the nightly digest, as every email webhook is, counts them in its next digest rather than sending each one.

Every event about a bill also carries the bill's tracking: one entry for each client that tracks it and one for your own work, with its position, priority, status, owner and tags, as the webhook's owner sees them and as /v1/tracked-items and the bill search list them. It's an empty list for a bill they track in nothing they can see, and it's left out when they can't read Tracked items.

Choose a Tracked items view as the scope and the webhook follows its items: their bills' events and the tracking events, for the items the view matches for its owner at the time. Its tracking lists hold only the view's items too, so a channel set up for one client's bills never carries another client's name or position.

Whose webhook it is#

A webhook sends what the person who owns it can see. If you change where someone else's webhook sends, which changes it sends or what it watches, it becomes yours: from then on it sends what you can see, and anything it was waiting to send is dropped rather than sent to the new place. The builder says so before you save, and the change is in the audit log. Renaming it, or changing its delivery or rate, leaves its owner as it was.

When someone else changes the view it sends from, it pauses. A saved view can have editors of its own: its owner, anyone it's shared with to edit, and the organization's Owners and Admins. If one of them changes the view's filters, or the bills in a list, every webhook on that view that belongs to someone else pauses as the change is saved. So does every such webhook on a view that reads the changed one: a Tracked items view filtered by it under Legislation saved view, a calendar view showing it under Legislation Views, or a view of Bills like that list. A scorecard counts too: an officials view filtered under Scorecard rating grades legislators by the scorecard as it is now, so when someone else changes the scorecard's bills, positions, session, chambers, members or rules, the webhooks on views rating by it pause the same way. Each owner is told in the app and by email or Slack or Teams as they've chosen on My profile. Nothing new goes out until the owner looks at the view and selects Resume. Nobody else can resume it or send it a test, though changing its destination, events or scope still makes it theirs, as above. A webhook whose owner is no longer recorded can be resumed by anyone who manages webhooks. Resuming drops whatever was made from the changed view while it was paused, so it's never sent, then or by a replay, and the webhook starts again from that moment. The view's editor sees how many webhooks a save will pause before saving, and each pause is in the audit log. A change of name, description, category or sharing, a new sort, or a list put in a new order doesn't change what the view matches, so it doesn't pause anything, and neither does an owner changing their own webhook's view. A view a webhook sends from can't be deleted on its own: deleting it deletes the webhook too, as Deleting something others depend on describes.

Payloads#

An HTTPS endpoint receives one JSON body per event, in the webhook's payload version: api_version in every body, and Payload version on the webhook's page. Every webhook is on 2026-10-01 today.

What each event carries#

data holds the record an event is about and what changed. These are the fields every body of that event has; a field marked sometimes is there only when it applies.

A body that would pass 64 KB is cut down to the record it's about, with "truncated": true. Read the rest through its links.

Payload versions#

When the format changes#

• Ignore fields you don't recognize. A new field can be added to a payload version at any time, and your code shouldn't fail on one it doesn't know.
• Anything else is a new version. A field renamed, moved or removed, a type changed, or a value or an event that now means something else, comes as a new payload version. Your webhook keeps receiving the version it's on, so your endpoint never gets a shape it wasn't written for.
• Slack, Teams and email aren't versioned. They're written for people, so they always use the latest wording.

Where a webhook can deliver#

Email always sends the nightly digest — one readable message a night, never one per change. Each-change delivery to an HTTPS endpoint, Slack or Teams needs a plan that includes it; see Plans and what they include.