23 October 2026: Company webhook recovery and Python client migration

Company webhooks now require explicit reactivation

Available in production, company record-event and date-due webhook subscriptions stop after three combined HTTP 400/404 responses, including retries, or immediately after HTTP 410. A 2xx response resets the counter. Only the affected company’s subscription stops; webhook definitions remain. These scoped failures no longer retain full dead-letter payloads.

Action required: Fix and test the destination, then explicitly reactivate the subscription to resume future deliveries. Tests and configuration pushes do not reactivate it, and old queued events are not replayed. See webhook recovery.

Python compatibility requirement: Published Python client 2.0.622 adds ApplicationsApi.reactivate_app_webhook(app_uuid, webhook_uuid) and company webhook runtime status. It also changes ShowResponseSubscribeWebhookDTO.data from a dictionary to a SubscribeWebhookDTO model. When upgrading, migrate dictionary access to attributes such as response.data.topic. Read runtime status through attributes because to_dict() excludes the read-only activation fields. See the Python response migration.