User story

If webhooks are disabled due to us not responding to the events coming from Shopware, we can't mitigate this programatically today. We must ask the client to uninstall and reinstall the app, which is not super efficient.

We want to be able re-register webhooks if they deactivate.

Acceptance criteria

Webhooks are re-registered when calling an API that registers webhooks.

Definition of Done

• Fulfills all acceptance criteria defined during discovery.
• Integration/E2E testing in staging is done.
• All integration/E2E/unit tests passing; all critical or high-priority bugs are resolved.
• Fulfills compliance, performance, security, and cloud-readiness needs.
• Observability—includes monitoring, alerting, and logging; incident response handbooks updated.
• Documentation—developer docs are written or updated, including information on how the feature or change is adopted and tested. If new functionality, end user documentation is written or updated.
• (conditional) All new API endpoints have a defined API schema.
• (conditional) If the change affects the Storefront, it has been tested in the latest three versions of Firefox, Chrome, Edge, IE11, and Safari, as well as the different viewports and devices (Desktop / Tablet / Mobile).
• (conditional) If the change affects the Administration, it has been tested in current versions of Firefox, Chrome, and Edge.
• (conditional) Functionality that includes new API routes are callable via the Store-API (/store-api/[version]/).
• (conditional) If a new Admin module is created, the access control layer is provided, and permissions can be managed via the Users & Permissions module.
• (conditional) If a new UI input field or interactive element is introduced, the ACL wrapper is added.
• (conditional) Performance testing done if the change has a high performance impact, such as affecting scalability, load balancing, or query optimization.