Azure Static Web Apps deployment failure — "No matching Static Web App was found or the api key was invalid"

Summary

GitHub Actions deployments to Azure Static Web Apps consistently fail with a BadRequest from Azure's content distribution server, reporting an invalid API key / no matching resource — on two separate, freshly created Static Web App resources, using two different deployment authorization methods. Configuration has been verified correct on both. This looks like an account/subscription-level backend issue rather than a misconfiguration.
Environment
GitHub repository: Glenclave/peterallenwindowsanddoors (private)
Azure subscription: "Azure subscription 1" (ID a3ce47fd-65cc-4c35-8980-4df78ef7d6d8) — status: Active
Resource group: Websites
Custom domain: peterallenwindowsanddoors.ie
Resource 1 (original)
Name: peterallenwindowsanddoors
Default hostname slug: yellow-meadow-0e7e9bc03
SKU: Free
Deployment method: classic deployment token (AZURE_STATIC_WEB_APPS_API_TOKEN_YELLOW_MEADOW_0E7E9BC03 GitHub secret)
Workflow file: .github/workflows/azure-static-web-apps-yellow-meadow-0e7e9bc03.yml
Resource 2 (newly created to test)
Default hostname slug: blue-meadow-0d4abb603
SKU: Free
Deployment method: created using the "GitHub" deployment authorization policy (Azure-managed GitHub App connection, not a manually-entered token) — however Azure still auto-generated a workflow that authenticates via a static secret, AZURE_STATIC_WEB_APPS_API_TOKEN_BLUE_MEADOW_0D4ABB603
Workflow file: .github/workflows/azure-static-web-apps-blue-meadow-0d4abb603.yml
Exact error
Try to validate location at: '/github/workspace'.

App Directory Location: '/' was found.

Try to validate location at: '/github/workspace/swa-db-connections'.

Looking for event info

The content server has rejected the request with: BadRequest

Reason: No matching Static Web App was found or the api key was invalid.

For further information, please visit the Azure Static Web Apps documentation at https://docs.microsoft.com/en-us/azure/static-web-apps/

If you believe this behavior is unexpected, please raise a GitHub issue at https://github.com/azure/static-web-apps/issues/

Exiting

Reproduced identically across multiple deployment attempts on both resources (Deployment IDs observed: 4b882c9d-4f9e-487d-97e5-0509f59ae9d9, 6565baea-85b4-4b72-9108-9b862d713696, among others).
Timeline / troubleshooting steps taken
Noticed a footer text fix committed on Aug 25 (Glenclave replacing Glenverse) was live in the GitHub repo but never appeared on the production site.
Confirmed via git push that the repo was already up to date with origin/main — the commit was on GitHub, ruling out a git/push problem.
Checked GitHub Actions → found the deploy workflow failing with the error above, going back to that commit.
Reset the deployment token in the Azure Portal (Overview → Manage deployment token → Reset), confirmed the new token was correctly copied (verified length ~119 characters via pbpaste | wc -c on macOS — an earlier attempt had accidentally copied a truncated 14-character value from the clipboard, which was caught and corrected).
Updated the AZURE_STATIC_WEB_APPS_API_TOKEN_YELLOW_MEADOW_0E7E9BC03 GitHub secret with the freshly reset, correct-length token. Confirmed via GitHub's "updated X minutes ago" timestamp that the save succeeded.
Re-ran the failed GitHub Actions job — same error.
Triggered a brand-new workflow run via an empty commit (git commit --allow-empty) rather than "re-run," to rule out any stale run-context caching — same error.
Confirmed in the Azure Portal that the resource genuinely has peterallenwindowsanddoors.ie listed under Custom domains, and that the portal's "View workflow" link correctly points at azure-static-web-apps-yellow-meadow-0e7e9bc03.yml, and "Source" shows main (GitHub) — i.e., Azure's own UI considers this resource correctly linked to the repo/branch/workflow.
Removed an OIDC-related step (Get Id Token / github_id_token input) from the workflow, suspecting an unconfigured federated credential trust — no change, same error.
Checked the Azure subscription status: Active, ruling out a billing/suspension cause.
Created an entirely new Static Web App resource (blue-meadow-0d4abb603) in the same resource group/subscription, this time explicitly choosing the "GitHub" deployment authorization policy during creation (Azure-managed connection) rather than the classic deployment-token model, specifically to rule out the token-management approach itself as the problem.
Azure auto-generated a new workflow file and GitHub secret for this new resource with no manual token handling on our part — the very first automated deployment failed with the identical error.
Verified the new workflow's app_location, api_location, and output_location values are correct for this plain static HTML site (no build step, no API). The failure occurs at the "Looking for event info" step, before/independent of any api_location-specific validation (which would produce its own distinct "Api Directory Location was not found" message if that were the cause — it does not appear).
What has been ruled out
Git push / repository sync issues
Stale or malformed deployment token (verified length and freshness)
Duplicate/mismatched GitHub secret name
Custom domain not actually attached to the resource being deployed to
Workflow/resource name mismatch (portal explicitly shows correct linkage)
OIDC id-token step interference
Subscription billing/suspension state
The specific deployment-token vs. GitHub-managed authorization policy choice (both fail identically)
api_location / app_location / output_location misconfiguration (values are correct for a static-only site; failure occurs upstream of build-path validation)
Smoking gun: identical workflow config, working then broken
Git history on the repository shows the Static Web Apps GitHub App bot auto-committed workflow adjustments on 2026-08-10 (commits e0c4bcd and efc1c57, "on-behalf-of: @Azure [opensource@microsoft.com](mailto:opensource@microsoft.com)" and a follow-up). The Azure Portal's own Environments page for the original resource shows the Production environment's last successful update as "Monday 10 August", status "Ready."

Every deployment attempt since — including the Aug 25 footer-text commit and every attempt made during this troubleshooting session in September — has failed with the error above, using a workflow file that is byte-for-byte identical to the one that deployed successfully on Aug 10 (confirmed via direct diff of the two file versions from git history; zero differences). No build/deploy configuration changed between the last known-good deployment and the first failure — only unrelated static page content changed in between.

This rules out workflow misconfiguration as the cause directly, rather than by elimination: the exact same configuration worked, then stopped working, with no corresponding change on the repository side. Whatever changed, changed on Azure's side.
Additional remediation attempts (resource 1, continued)
Disconnect/reconnect GitHub source: checked the Portal UI (Settings, Overview, the "..." menu, and the Environments page) for a way to disconnect and reconnect the GitHub source on the original resource without recreating it. No such option is exposed for this resource (deployment-token-based authorization). Not available as a self-service option here.
Azure CLI token reset: ran az staticwebapp secrets reset-api-key --name peterallenwindowsanddoors --resource-group Websites, which completed with exit code 0 (no error). Confirmed via az staticwebapp secrets list that a freshly generated, well-formed token was issued (ends in ...0e7e9bc03, correctly matching this resource's own hostname suffix — i.e., the token is unambiguously scoped to the right resource). Copied it directly via pbcopy (no manual clipboard step) into the GitHub secret and triggered a fresh deployment via an empty commit. Result: identical failure, ruling out portal-vs-CLI reset mechanics as a distinguishing factor.
Azure's built-in "Diagnose and solve problems" troubleshooter: opened the "Content Deployment" category specifically. The diagnostic itself fails to load, showing "Sorry, an error occurred. Please refresh the page and try again." — persists after a refresh. Azure's own first-party diagnostics tooling cannot retrieve data for this resource, which is consistent with (and adds further weight to) a backend-side fault rather than a client-side configuration issue.

Conclusion
Every self-service remediation path available through the Portal, GitHub, and the Azure CLI has been exhausted, across two separate resources and two separate authorization models, with a confirmed working-then-broken configuration (see "Smoking gun" above) and a CLI-verified, correctly-issued, resource-matched token still being rejected identically. There is no remaining self-service action expected to change the outcome.
Ask
Given the same failure occurs on two separate resources using two different authorization models, with a CLI-issued and resource-matched token still rejected, and with proof that an identical configuration worked before a specific date and has failed ever since — this is a backend state or account-level issue on Azure's Static Web Apps service for this subscription, not a client-side configuration problem. Requesting investigation into why deployment requests for subscription a3ce47fd-65cc-4c35-8980-4df78ef7d6d8 are being rejected as "no matching Static Web App / invalid API key" despite valid, freshly issued, correctly-scoped tokens and correctly linked resources.

Start with .github/workflows/azure-static-web-apps-yellow-meadow-0e7e9bc03.yml and .github/workflows/azure-static-web-apps-blue-meadow-0d4abb603.yml, then reproduce the deployment failure and review the Azure Static Web Apps content-deployment diagnostics. Done means identifying the backend or subscription-level cause, or documenting a confirmed remediation for the rejected deployments.

Written by the indexing model from the issue text.