Azure Notification Hubs FCM v1: Portal Test Send shows "0 passed, 0 failed" and metric "FCMv1 Invalid Notification Format" — Firebase Console works with same token

Question

Azure Notification Hubs FCM v1: Portal Test Send shows "0 passed, 0 failed" and metric "FCMv1 Invalid Notification Format" — Firebase Console works with same token

Zuozhen 20

Summary

We are integrating Azure Notification Hubs (FCM v1) for Android push in a React Native (Expo) app. Firebase Console test campaigns deliver notifications successfully to the same device using the same FCM registration token. Azure Notification Hubs does not — Portal Test Send reports success but 0 passed / 0 failed with an empty results table, and our hub metrics show FCMv1 Invalid Notification Format (Sum) spikes.

We need guidance on: (1) correct Portal Test Send usage for FCM v1 with a raw device token vs tag-based registrations, (2) the exact JSON body Azure expects for FCM v1 (Portal vs Direct Send vs SDK), and (3) whether our observed metrics indicate payload format issues vs credential/registration issues.

Environment

| Item | Value |

|------|--------|

| Notification Hub namespace | <our-namespace> (test/staging ring) |

| Notification Hub name | <our-hub-name> |

| Resource group | <our-resource-group> |

| Subscription | <redacted — standard Azure subscription> |

| Firebase / GCP project | <our-firebase-project-id> |

| Android package | <our.android.package.name> |

| Client SDK | expo-notifications → raw FCM registration token (not Expo Push Token) |

| Backend (planned) | @azure/notification-hubs SDK — direct send via { deviceHandle: fcmToken }, no NH registrations/installations |

| PNS config | Azure Portal → Notification Hub → Google (FCMv1) (not legacy GCM/FCM) |

Problem

Firebase Console (same Firebase project, Cloud Messaging compose / test campaign) → notification arrives on device ✅
Azure Portal → Test Send (platform Android (FCM v1)) → toast says test message sent successfully, but result is {0 passed, 0 failed} and the Results table is empty ❌
Metrics on our hub → FCMv1 Invalid Notification Format (Sum) shows non-zero counts over 24h ❌
We do not consistently see FCMv1 Authorization Errors in the same period (credentials may be partially OK; format/targeting may be wrong).

What we have already verified

A. Google Cloud / Firebase side

Firebase Cloud Messaging API (fcm.googleapis.com) is enabled for our GCP project.
FCM registration token is valid — proven by successful delivery from Firebase Console using the same token.
Service account configured in Azure NH FCMv1 settings: <firebase-adminsdk-xxxxx>@<project-id>.iam.gserviceaccount.com
- Role: Firebase Admin SDK Administrator Service Agent (default Firebase Admin SDK SA).
- We have not added extra roles (e.g. Firebase Cloud Messaging Admin) yet.

B. Azure Notification Hub side

Configured under Google (FCMv1) with Project ID, Client Email, and Private Key from the Firebase service account JSON (not legacy Server Key / GCM/FCM API key page).
Legacy Google (GCM/FCM) page is not used.

Zuozhen 20

Steps we tried (Portal Test Send)

Platform: Android (FCM v1)
Send to Tag Expression: we pasted the full FCM registration token
(e.g. <token-prefix>...<token-suffix> — typical APA91b… format, ~150+ chars)

Payloads tried (all wrapped in message per migration docs):

Attempt 1 — Microsoft migration doc example:

{
  "message": {
    "notification": {
      "title": "Breaking News",
      "body": "FCMv1 is ready."
    },
    "android": {
      "data": {
        "name": "wrench",
        "mass": "1.3kg",
        "count": "3"
      }
    }
  }
}

Attempt 2 — minimal notification:

{
  "message": {
    "notification": {
      "title": "Azure NH test",
      "body": "hello from azure"
    }
  }
}

Attempt 3 — with android.data:

{
  "message": {
    "notification": {
      "title": "Azure NH test",
      "body": "hello"
    },
    "android": {
      "data": {
        "type": "announcement"
      }
    }
  }
}

Result for all attempts: Portal toast = success, but 0 passed, 0 failed, empty Results grid, no delivery on device.

Observed metrics (evidence)

Metric	Observation
`FCMv1 Invalid Notification Format (Sum)`	Non-zero over 24h — suggests some outbound FCM v1 requests had invalid JSON shape
`FCMv1 Authorization Errors`	Not the primary signal in our case
Portal Test Send	Always 0 passed / 0 failed when FCM token pasted into Tag Expression

We also previously sent legacy-shaped payloads (top-level { "notification": {...} } without message wrapper), which likely contributed to Invalid Notification Format per FCM migration REST doc.

Expected vs actual

Scenario	Expected	Actual
Firebase Console → FCM token	Device receives notification	✅ Works
Azure Portal Test Send + FCM token in tag field	Unclear — we assumed direct token targeting	❌ 0/0, no delivery
Azure NH → FCM v1 with correct `message` payload	Device receives notification	❌ Not confirmed yet
Metric after valid send	Success / Enqueued outcomes	❌ Invalid Notification Format spikes

Yohannes Damtie 0 Reputation points

2026-07-08T17:04:33.8233333+00:00
Based on the information provided, the issue does not appear to be with the FCM token or Firebase configuration. Since Firebase Console successfully delivers to the same token, the device registration and Firebase project setup are most likely correct.

The failure is likely happening in the Azure Notification Hubs FCM v1 layer — either the notification target resolution (registrations/installations vs raw token) or the payload transformation Azure performs before sending to FCM.

If the application does not require Azure Notification Hub features such as tags, templates, or Azure-managed audiences, you can simplify the architecture by sending directly to FCM HTTP v1 using the device registration token.

For example, a backend can send directly:

import { send } from "expo-push-easy"; await send(fcmToken, { title: "Test notification", body: "Hello from FCM v1" }, { serviceAccount });

This avoids the additional Azure translation layer and sends a native FCM v1 payload directly to Google's FCM API.

For debugging the current Azure setup, I would verify:

The device is actually registered inside Notification Hubs (Portal Test Send targets registrations, not just an arbitrary raw FCM token).

The hub is configured for FCM v1 and not legacy GCM/FCM.

The generated FCM v1 payload contains the correct message structure.

Azure metrics showing FCMv1 Invalid Notification Format indicate the request reached FCM but the payload was rejected, so focus on payload generation rather than the device token.

If the goal is simply "send push notifications to Expo/React Native users from a backend", a direct FCM v1 integration is usually simpler than introducing Notification Hubs.

Answer accepted by question author

0 additional answers

Your answer

Zuozhen 20 Reputation points

2026-07-07T12:30:27.91+00:00

Steps we tried (Portal Test Send)

Platform: Android (FCM v1)
Send to Tag Expression: we pasted the full FCM registration token
(e.g. <token-prefix>...<token-suffix> — typical APA91b… format, ~150+ chars)

Payloads tried (all wrapped in message per migration docs):

Attempt 1 — Microsoft migration doc example:

{ "message": { "notification": { "title": "Breaking News", "body": "FCMv1 is ready." }, "android": { "data": { "name": "wrench", "mass": "1.3kg", "count": "3" } } } }

Attempt 2 — minimal notification:

{ "message": { "notification": { "title": "Azure NH test", "body": "hello from azure" } } }

Attempt 3 — with android.data:

{ "message": { "notification": { "title": "Azure NH test", "body": "hello" }, "android": { "data": { "type": "announcement" } } } }

Result for all attempts: Portal toast = success, but 0 passed, 0 failed, empty Results grid, no delivery on device.

Observed metrics (evidence)

Metric Observation

FCMv1 Invalid Notification Format (Sum) Non-zero over 24h — suggests some outbound FCM v1 requests had invalid JSON shape

FCMv1 Authorization Errors Not the primary signal in our case

Portal Test Send Always 0 passed / 0 failed when FCM token pasted into Tag Expression

We also previously sent legacy-shaped payloads (top-level { "notification": {...} } without message wrapper), which likely contributed to Invalid Notification Format per FCM migration REST doc.

Expected vs actual

Scenario Expected Actual

Firebase Console → FCM token Device receives notification ✅ Works

Azure Portal Test Send + FCM token in tag field Unclear — we assumed direct token targeting ❌ 0/0, no delivery

Azure NH → FCM v1 with correct message payload Device receives notification ❌ Not confirmed yet

Metric after valid send Success / Enqueued outcomes ❌ Invalid Notification Format spikes
Yohannes Damtie 0 Reputation points

2026-07-08T17:04:33.8233333+00:00

Based on the information provided, the issue does not appear to be with the FCM token or Firebase configuration. Since Firebase Console successfully delivers to the same token, the device registration and Firebase project setup are most likely correct.

The failure is likely happening in the Azure Notification Hubs FCM v1 layer — either the notification target resolution (registrations/installations vs raw token) or the payload transformation Azure performs before sending to FCM.

If the application does not require Azure Notification Hub features such as tags, templates, or Azure-managed audiences, you can simplify the architecture by sending directly to FCM HTTP v1 using the device registration token.

For example, a backend can send directly:

import { send } from "expo-push-easy"; await send(fcmToken, { title: "Test notification", body: "Hello from FCM v1" }, { serviceAccount });

This avoids the additional Azure translation layer and sends a native FCM v1 payload directly to Google's FCM API.

For debugging the current Azure setup, I would verify:

The device is actually registered inside Notification Hubs (Portal Test Send targets registrations, not just an arbitrary raw FCM token).

The hub is configured for FCM v1 and not legacy GCM/FCM.

The generated FCM v1 payload contains the correct message structure.

Azure metrics showing FCMv1 Invalid Notification Format indicate the request reached FCM but the payload was rejected, so focus on payload generation rather than the device token.

If the goal is simply "send push notifications to Expo/React Native users from a backend", a direct FCM v1 integration is usually simpler than introducing Notification Hubs.

Answer 1

Hi @Zuozhen ,

Thanks for reaching out in Microsoft Q&A forum,

Based on the information provided, the issue appears to be related to a targeting issue in the Portal Test Send and a separate FCM v1 payload format issue, rather than a credential issue.

In Azure Notification Hubs, Send to Tag Expression is meant for Notification Hubs tags, not for a raw FCM registration token. So if you paste the FCM token there and the hub has no registration or installation that matches that token as a tag, the send can complete with 0 passed / 0 failed and an empty results table. That behavior is expected and does not mean the FCM token itself is invalid.

The other signal, FCMv1 Invalid Notification Format, strongly suggests that at least some of the payloads sent to the hub were not in the correct FCM v1 shape. For FCM v1, the payload needs to use the top-level message wrapper. Legacy payloads such as a top-level notification object without message can trigger this metric. Your newer examples that use message.notification are the right direction.

Portal Test Send is not the right way to test a raw FCM token unless that token exists as a tag or registration in Notification Hubs.
Direct Send through your backend is the correct model for your architecture, where the raw FCM token is used as the device handle.
The Invalid Notification Format metric points more to payload structure issues than to authentication, especially since Firebase Console can already deliver to the same device token successfully.

Because Firebase Console delivery works with the same token, and you are not seeing strong authorization failures in Notification Hubs, credentials are less likely to be the primary problem. The more likely causes are using the token in the wrong portal field and earlier sends using legacy or malformed FCM payloads.

Recommended next step: validate the backend direct-send flow with a minimal FCM v1 payload like this:

{
  "message": {
    "notification": {
      "title": "Azure NH test",
      "body": "Hello"
    }
  }
}

If that succeeds, you can then add android.data fields as needed.

Reference:

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Zuozhen 20 Reputation points

2026-07-08T03:57:14.47+00:00

Hi Venkatesan S ,

Thank you for the helpful and thorough answer. It clearly explained why Portal Test Send showed 0/0 when we pasted an FCM token into the tag field, and why the Invalid Notification Format metric likely reflects payload shape rather than credentials.

We’ll validate via backend Direct Send with the minimal message payload you recommended. Thanks again for your support.

Best regards, Zuozhen
Venkatesan S 10,750 Reputation points Microsoft External Staff Moderator

2026-07-08T10:17:36.6533333+00:00

Hi @Zuozhen
If the information provided resolves your issue, please click and consider upvoting it, as this may help other community members facing a similar situation. After you accept the answer, and with your permission, we will proceed with closing the case.