Register dynamic Jira Cloud webhooks via REST with a JQL filter and keep them alive past the 30-day expiry

Documented steps

1. Check eligibility first: POST /rest/api/3/webhook is available ONLY to Connect and OAuth 2.0 apps. Plain API-token/Basic-auth scripts cannot register webhooks this way and must use the Jira admin UI (Settings > System > WebHooks) instead.
2. Register: POST /rest/api/3/webhook with body {"url":"https://example.com/hooks/jira","webhooks":[{"events":["jira:issue_created","jira:issue_updated"],"jqlFilter":"project = ABC"}]}.
3. jqlFilter is REQUIRED on every webhook entry. Only a subset of JQL is accepted: fields issueKey, project, issuetype, status, assignee, reporter, issue.property and cf[id] (custom fields limited to the epic label field), with operators =, !=, IN and NOT IN only. No functions, no ORDER BY.
4. To narrow jira:issue_updated to specific fields, add "fieldIdsFilter":["summary","customfield_10029"] so you are not woken by every edit.
5. Parse the per-entry result: {"webhookRegistrationResult":[{"createdWebhookId":1000},{"errors":["..."]}]}. A batch can PARTIALLY succeed — check every array element, not just the HTTP status.
6. Schedule a refresh job: webhooks registered through the REST API expire after 30 days. Call PUT /rest/api/3/webhook/refresh with the webhook IDs on a recurring schedule (weekly is a safe margin) to extend them.
7. Monitor delivery: GET /rest/api/3/webhook/failed?maxResults=100&after=<epoch_ms> returns failed deliveries oldest first. Page by using the last failure's timestamp as the next 'after' value, or follow the 'next' link.
8. List and clean up with GET /rest/api/3/webhook and DELETE /rest/api/3/webhook (body with an ID array). Both act only on webhooks owned by your app.
9. Make your receiver idempotent and fast: acknowledge with 2xx immediately and process asynchronously.