Function App: ZIP publish returns HTTP 400 without deployment ID — Deployment validation issue

I prepared the recommended config-zip --build-remote false --timeout 600 --debug attempt, but stopped before invoking it. Azure CLI 2.89.0 reads Function App app-setting values during runtime validation before reaching the deployment step.

Please confirm whether this read is required by the supported command. If it is, is there a documented method to suppress those values from debug output while preserving the diagnostic details you need? Otherwise, please provide a supported deployment method that avoids reading app-setting values.

Thank you for the guidance. To clarify our environment:

• Azure Functions Flex Consumption
• Node.js 22, JavaScript v4 programming model
• Azure CLI 2.89.0
• Prebuilt ZIP with host.json, package.json and package-lock.json at the archive root
• Package size: approximately 633 MB
• ZIP integrity and function registrations verified

We already tried:

az functionapp deployment source config-zip \

--resource-group <resource-group> \

--name <function-app> \

--src <package.zip> \

--build-remote false \

--timeout 600

It returned HTTP 400 without a captured deployment ID. Microsoft

Support reports that the earlier failed request did not activate a

new deployment; the precise rejection reason remains unresolved.

The response body was not retained, which is our main diagnostic gap.

Is there a supported read-only way to recover the failed publish

response or validation reason? If another --debug deployment attempt

is required, what is the recommended safe capture/redaction procedure?

Could you also clarify which recommendations apply specifically to

Flex Consumption? Microsoft's Flex guidance says not to introduce

WEBSITE_RUN_FROM_PACKAGE, and the Flex publish endpoint is /api/publish

rather than the older /api/zipdeploy path.

We have an open Azure Support case and are preserving the existing

packages and configuration while investigating.

Hello Javonte Maynor,

Greetings! Thanks for raising this question in the Q&A forum.

An HTTP 400 with no deployment ID means the deployment service (Kudu/SCM, or the Flex Consumption publish endpoint) rejected the request during validation. The request failed before a deployment record was created, which is why there is no ID to look up. The question doesn't include the plan type, the exact command, or the response body, so I can't pin down the cause. The usual reasons are a deployment method that doesn't match the hosting plan, a malformed or wrongly structured ZIP, or an authentication or SCM access setting that blocks the request. Please work through these steps.

1. Identify your hosting plan. The supported ZIP method depends on the plan. Run:

az functionapp show --name <app-name> --resource-group <rg-name> --query "{kind:kind, sku:sku, state:state}"

You can also check Overview in the portal. Flex Consumption apps use the /api/publish endpoint and do not support the older WEBSITE_RUN_FROM_PACKAGE flow in the same way as Consumption, Premium or Dedicated plans.

1. Deploy with the supported CLI command and capture the full error. Use --debug so the actual 400 response body is printed:

az functionapp deployment source config-zip --resource-group <rg-name> --name <app-name> --src <path-to-package>.zip --debug

For Flex Consumption you can add --build-remote false to skip the remote build. The response body usually names the exact validation problem.

Check the ZIP structure. host.json must be at the root of the ZIP, not inside a parent folder. Zip the contents of the project output folder, not the folder itself. For .NET, publish first with dotnet publish -c Release -o ./publish and zip the contents of publish. For Python or Node.js, make sure host.json, requirements.txt or package.json, and your function folders are at the root.

Check that the package is not corrupted or oversized. Confirm the file opens locally and was created with a standard ZIP tool. Rebuild it if there is any doubt. Very large packages are better served with the run-from-package approach in the next step.

Try the run-from-package method as an alternative. Upload the ZIP to a blob container, then point the app at it:

az storage blob upload --account-name <storage-account> --container-name <container> --name app.zip --file <path-to-package>.zip --auth-mode login

az functionapp config appsettings set --name <app-name> --resource-group <rg-name> --settings WEBSITE_RUN_FROM_PACKAGE="<blob-url-with-SAS-or-use-managed-identity>"

Restart the app afterwards with az functionapp restart --name <app-name> --resource-group <rg-name>. This avoids the SCM upload path and does not change any other configuration or require a remote build.

Check authentication and SCM access if you use the REST API. If you call the endpoint directly, the request must be a POST to https://<app-name>.scm.azurewebsites.net/api/zipdeploy with the ZIP as the body and valid deployment credentials or an Entra ID access token. If basic authentication for SCM is disabled in the app's settings, use an access token from az account get-access-token, and check that no network restriction (IP restrictions, private endpoint only) blocks the SCM site from your build agent.

Escalate if the 400 remains. If the debug output shows no useful message and the ZIP structure and plan are confirmed correct, please open an Azure Support request under Function App deployment. Include the subscription ID, app name, region, hosting plan, the full --debug output, the x-ms-request-id or correlation ID from the failed response, and the UTC time of the attempt so the team can trace the rejected request.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,
Jerald Felix