Allow passing applicationId via Headers for /application.redeploy (Webhook compatibility)

What problem will this feature address?

Currently, the /application.redeploy endpoint strictly requires the applicationId to be sent inside the request body.

This creates a significant blocking issue when trying to trigger deployments from third-party tools with limited webhook customization, such as Strapi (Headless CMS). Strapi, and many other services, allow users to configure the target URL and custom HTTP Headers, but they do not allow modifying the JSON body of the POST request (they usually send their own event payload automatically).

Because Dockploy does not check the headers for the ID, it is impossible to trigger a redeploy directly from these tools, breaking the CI/CD workflow for content updates.

Describe the solution you'd like

I would like the /application.redeploy endpoint to accept the applicationId via a custom HTTP Header as an alternative to the body.

Proposed Logic:
The controller should prioritize the body (for backward compatibility) but fallback to checking a specific header if the body property is missing.

Suggested Header: x-application-id

Example of the desired webhook configuration:

POST /api/application.redeploy
Host: dockploy.instance.com
x-application-id: clh1234567890
Content-Type: application/json

// The body can remain as the default payload sent by the external tool (e.g., Strapi event data)

Describe alternatives you've considered

The only current workaround is to implement a "middleware" or proxy service (like an n8n workflow, a Lambda function, or a custom Node.js script).

This middleware acts as a bridge: it receives the webhook from Strapi, extracts the ID (or has it hardcoded), constructs a new request with the applicationId in the body, and sends it to Dockploy.

This is an inefficient solution that adds unnecessary complexity, latency, and points of failure for what should be a simple HTTP trigger.

Additional context

This feature is critical for Headless CMS workflows where content updates (e.g., "Publish") need to trigger a frontend rebuild automatically.

• Tool causing the issue: Strapi (Headless CMS)
• Affected Endpoint: /application.redeploy

Will you send a PR to implement it?

No

Start at the controller entry point for /application.redeploy and inspect how applicationId is read from the request body. Add the proposed x-application-id fallback while preserving body precedence, then verify that redeploy requests work with the header and that existing body-based requests remain supported.