The next decisive test is to deploy the seven failing handlers from a minimal Node.js v4 entry point with no application imports, because a bare /api/* 404 with no request telemetry means the handler is not registered or the request is not being forwarded to it—not that its handler returned 404.

1. Isolate registration from application startup

Node.js v4 discovers functions by executing the files selected by package.json.main; each handler must be registered through app.http(). The @azure/functions package must be under dependencies, and the main path or glob must include every compiled registration file.^1^

Create one temporary registration file containing a failing route and no imports from the application:

const { app } = require("@azure/functions");

app.http("registrationProbe", {
  route: "registration-probe",
  methods: ["GET"],
  authLevel: "anonymous",
  handler: async (request, context) => {
    context.log("registrationProbe reached");
    return { status: 200, jsonBody: { registered: true } };
  }
});

Then ensure api/package.json directly loads it:

{
  "main": "src/registration-probe.js",
  "dependencies": {
    "@azure/functions": "^4.0.0"
  }
}

For TypeScript, point main at the compiled JavaScript, for example dist/src/registration-probe.js, not the .ts source. Node.js v4 registration is code-centric, and v3 and v4 functions cannot be mixed in one app.^2^

After deployment, request:

GET /api/registration-probe

Interpret the result:

• 200: Managed Functions routing works. Restore the original entry point, then add the failing modules back one at a time. The first import that changes the probe to 404 identifies a module-load or registration failure.
• Platform 404: The failure remains with a dependency-free registration, making an application route or imported dependency an unlikely explanation. Preserve this deployment as the minimal reproduction for Azure Support.

An open Static Web Apps report documents that a top-level exception in a Node.js v4 function or imported module can leave handlers unregistered while requests return 404.^3^ Another open report describes silent registration loss in managed Node.js v4 deployments, although its reported approximately 39-handler boundary does not match this nine-handler case and therefore does not establish the cause here.^4^

2. Check registration inputs, not route spelling

For the original package, verify these concrete items:

1. api/package.json has a main value covering all registration files, such as:
   • JavaScript: src/functions/*.js
   • TypeScript: dist/src/functions/*.js
2. @azure/functions is in dependencies, not devDependencies.
3. Every failing module reaches its app.http(...) call without first constructing clients, reading required environment variables, or executing other startup code that can throw.
4. Each function name passed as the first app.http() argument is unique.
5. The route excludes the /api prefix:

      app.http("adminProjects", {
        route: "admin-projects",
        methods: ["GET"],
        handler: adminProjects
      });
   

Static Web Apps supplies /api as the fixed API prefix; managed APIs are HTTP-only and have additional runtime and application-setting restrictions.^5^

A frontend navigation fallback is not the appropriate fix: that mechanism handles client-side page routes and does not register an API handler.^6^

3. Capture evidence for the support ticket

Open the repository’s Actions → affected workflow → Build and Deploy Job → Build And Deploy, then retain the complete API/Oryx section. Static Web Apps records package-installation, build, and folder-validation messages there, even when the overall workflow succeeds.^7^

Attach:

• The minimal probe’s commit and workflow run.
• Exact UTC request times and response headers/body.
• Confirmation that the probe produces no Application Insights request.
• The function list from APIs → Backend Details → Functions.
• Results from both resources and regions.
• api/package.json, host.json, and the entry-point file.
• Oryx and Node versions shown in the deployment log.

Since redeployment, route renaming, and cross-region resource recreation have already failed, repeating those actions adds no diagnostic value.

Conditional workaround

If the minimal probe still receives the platform 404, test a separately deployed Function App only if upgrading to Standard is acceptable. The Free plan supports managed Functions only; linking an existing Function App requires Standard.^8^ If the same code works there, that cleanly separates the application from the managed-Functions registration path and provides a practical workaround while Support investigates.

References

1. Migrate to version 4 of the Node.js programming model for Azure Functions (programming-language-typescript)
2. Azure Functions Node.js developer reference | Microsoft Learn
3. #1554 All api requests return 404 not found -- can't troubleshoot
4. Regression: SWA managed Functions silently cap new deploys at ~39 app ...
5. API support in Azure Static Web Apps with Azure Functions
6. Azure Static Web Apps Frequently Asked Questions
7. Troubleshooting Azure Static Web Apps | Microsoft Learn
8. Azure Static Web Apps hosting plans