Update a webhook endpoint

Every call needs webhooks:manage. Changing url or subscribed_events, or setting is_active to true, also needs reservations:read, because each of those steers the endpoint that receives whole reservations. What counts is the change, not the field you send: we compare your body against the stored endpoint, so a url or a subscribed_events list you send back unchanged costs nothing, and neither does is_active: true on an endpoint already on. Send back the endpoint you read from GET /rs/v1/webhooks with is_active flipped to false and webhooks:manage alone is enough. A 403 names the fields that asked for more. Setting is_active to false and rotating the secret need webhooks:manage alone, so you can always stop a stream or replace a leaked secret. That also means a key holding webhooks:manage alone can mint a new secret and read it in full, and that secret is the key that signs reservation events into your endpoint. A body that does both needs both scopes. Changes the URL, the subscribed events, or the active flag. Every field is optional, but the body must carry at least one of them: an empty object is rejected with 400 VALIDATION_ERROR. Concurrent PUTs are last write wins: every field you send is written whether or not it changed, so a body built from a stale GET puts back what it read, undoes a change another caller made in between, and still answers 200. Set is_active to false to stop deliveries without giving up the slot. While an endpoint is inactive no new event is queued for it, but a delivery already queued gets no promise either way: it is discarded only if a sweep picks it up while the endpoint is still off, so switching back on quickly can let the whole backlog through. Do not build on either outcome. Point an existing endpoint at a new URL to reuse a slot, but repoint only to a host you control: the URL is read when a delivery is sent, not when it is queued, so every pending delivery built up under the old URL goes to the new host, and a backlog spanning about three hours of the retry schedule can arrive as a burst. Send rotate_secret: true to mint a new secret. The response returns it in full exactly once, and new deliveries are signed with it at once, but a delivery already picked up for sending keeps the old secret for up to 90 seconds. Accept both signatures for a few minutes after a rotation rather than cutting the old one off. Rotation is not idempotent, and this endpoint ignores Idempotency-Key: a PUT you retry after a lost response rotates a second time, and the secret from the first rotation is gone for good, so deliveries signed with it can never be verified. If a rotate response goes missing, rotate again and use the secret you get back.