Fluxguard

Delete one webhook by `id` -- named in the request BODY, not the path -- so Fluxguard stops POSTing change notifications to it. There is no undo: restoring delivery means registering the URL again, which mints a new id. The monitored pages themselves are untouched, so this stops the notifications rather than the monitoring via DELETE /account/webhook

DESTRUCTIVE. Delete a monitored site by id. Irreversible: the site's sessions, its pages and every capture and diff Fluxguard has stored under them go with it, and the contract publishes no undelete and no archive. To stop watching ONE page while keeping the site, use `Delete a monitored page`; to stop being notified without deleting anything, delete the webhook via DELETE /site/{siteId}

DESTRUCTIVE. Delete one monitored page out of a session. Irreversible: that page's captures and diff history go with it, and the contract publishes no undelete. The site, the session and the session's other pages stay, which makes this the NARROW alternative to `Delete a site` via DELETE /site/{siteId}/session/{sessionId}/page/{pageId}

Read the connected Fluxguard organization's account attributes. The cheapest read on the surface, the one Fluxguard's own documentation offers as its smoke test, and the call this integration probes a pasted key with. Takes no parameters via GET /account

List every category in the account, returned as an object KEYED BY CATEGORY ID -- not as an array -- each entry carrying its name and whether it groups SITES or PAGES. These ids are what `Add a page to monitor` files a new site under via GET /account/category

List the webhooks on the account, each with the URL Fluxguard POSTs change notifications to and the id `Delete a webhook` needs. Returns the whole list in one body -- there is no cursor and no page argument via GET /account/webhook

Return a sample webhook body -- built from this account's own data, or from stock data when the account is new -- so a receiving endpoint can be written and tested before a real change fires. The payload names the site, session and page, the base URL and file names for the captured html, text, visual and network artifacts and for each diff, the diff summary and diff URL, any alarms that triggered, and whether AI flagged the change via GET /account/webhook/sample

Read the stored data Fluxguard holds for one monitored page, addressed by all three of `siteId`, `sessionId` and `pageId` exactly as `Add a page to monitor` returned them via GET /site/{siteId}/session/{sessionId}/page/{pageId}

Create a SITE category from a `name` and get its id back. Fluxguard has two category kinds, site and page, and this call makes the site kind only; the contract publishes no way to rename or delete one afterwards, so a typo is permanent. The returned id is what `Add a page to monitor` takes as `categoryId` via POST /account/category

Put a URL under monitoring. WITHOUT `siteId` and `sessionId` this CREATES a new site and session for it, optionally named with `siteNickname` and filed under a category by `categoryId`, `categoryName` or a list of `categories`; WITH both it adds the page to that existing session instead, and the category arguments are ignored. Returns the `siteId`, `sessionId` and `pageId` that every other site-scoped tool here takes via POST /add-page

Start a crawl of one session now instead of waiting for its schedule -- the call to make after adding pages, or to force a fresh capture and comparison. It re-captures the session's pages and diffs them against the previous capture, so it CAN cause webhook deliveries; it creates and removes nothing. Takes no body via POST /site/{siteId}/session/{sessionId}/crawl

Register a `url` for Fluxguard to POST a change notification to whenever a monitored page changes, and get the webhook's id back. Fluxguard signs each delivery with a `fluxguard-signature` header computed from a SEPARATE secret shown in the org settings; that secret verifies Fluxguard to your endpoint and is not this connection's API key, so nothing is pasted for it here. Read `Get a sample webhook payload` first to see the body your endpoint will receive via PUT /account/webhook