Why do the APNS and FCM templates have such different JSON structures for what's conceptually the same notification?

Each push notification platform defines its own required payload schema, APNS wraps content under an aps key with alert/badge/sound fields, while FCM's v1 API wraps it under message.notification and message.data. Notification Hubs' templated registration approach lets application code send one logical payload with placeholders ($(title), $(message)) and have the hub apply each platform's own required structure automatically, rather than the sending application needing to construct platform-specific payloads itself.

What's the risk of using DefaultFullSharedAccessSignature everywhere instead of a scoped rule like BackendSendOnly?

The full rule grants Listen, Manage, and Send rights together, if a credential using that rule leaks (checked into a repo, exposed in a client app, logged accidentally), the leaked credential can be used not just to send notifications but to manage the hub's configuration and read registration data. A backend service that only ever needs to send notifications should use a Send-only scoped rule specifically to limit the blast radius of a potential credential leak.

Does googleProjectId plus serviceAccountJson replace the older FCM legacy server key approach?

Yes, this is the fcmV1 credential type specifically for Google's newer, service-account-based FCM HTTP v1 API, which is the direction Google has moved FCM authentication toward, replacing the older, simpler server key approach. If you're setting up a new Notification Hub integration with Android, fcmV1 with proper service account credentials is the current recommended path rather than a legacy server key configuration.

Azure Notification Hub Config Builder

ServerlessAzure

Build Notification Hub registration configs with APNS, FCM, and WNS platform credentials, template registrations, and SAS rules.

Azure Notification Hubs Configuration

Build Notification Hub registration configs with APNS, FCM, and WNS platform credentials, template registrations, and SAS authorization rules.

Required Fields

namespaceNamehubNameresourceGroupskuplatformCredentialsregistrations

{
  "namespaceName": "ntfns-contoso-prod",
  "hubName": "ntf-contoso-mobile",
  "resourceGroup": "rg-notifications",
  "location": "eastus2",
  "sku": "Standard",
  "platformCredentials": {
    "apns": {
      "apnsCertificate": "<base64-encoded-p12>",
      "certificatePassword": "<password>",
      "endpoint": "gateway.push.apple.com",
      "appName": "com.contoso.mobileapp",
      "keyId": "ABC123DEFG",
      "appId": "TEAM123456",
      "token": "<p8-key-content>"
    },
    "fcmV1": {
      "googleProjectId": "contoso-mobile-12345",
      "serviceAccountJson": "<service-account-key-json>"
    },
    "wns": {
      "packageSid": "ms-app://s-1-15-2-1234567890-1234567890-1234567890-1234567890-1234567890-1234567890-1234567890",
      "secretKey": "<wns-secret>",
      "windowsLiveEndpoint": "https://login.live.com/accesstoken.srf"
    }
  },
  "registrations": [
    {
      "description": "iOS production push",
      "platform": "apple",
      "tags": ["prod", "ios", "premium-user"],
      "template": {
        "body": "{\"aps\":{\"alert\":{\"title\":\"$(title)\",\"body\":\"$(message)\"},\"badge\":$(badge),\"sound\":\"default\"},\"customData\":{\"orderId\":\"$(orderId)\"}}",
        "expiry": "$(expiry)",
        "priority": "10"
      }
    },
    {
      "description": "Android production push",
      "platform": "fcmV1",
      "tags": ["prod", "android", "premium-user"],
      "template": {
        "body": "{\"message\":{\"notification\":{\"title\":\"$(title)\",\"body\":\"$(message)\"},\"data\":{\"orderId\":\"$(orderId)\"},\"android\":{\"priority\":\"high\"}}}"
      }
    }
  ],
  "authorizationRules": [
    {
      "name": "DefaultListenSharedAccessSignature",
      "rights": ["Listen"]
    },
    {
      "name": "DefaultFullSharedAccessSignature",
      "rights": ["Listen", "Manage", "Send"]
    },
    {
      "name": "BackendSendOnly",
      "rights": ["Send"]
    }
  ],
  "tags": {
    "environment": "production",
    "team": "mobile"
  }
}

Generated Output

Output will appear here...

About This Tool

Build an Azure Notification Hub with per-platform credentials (APNS certificate or token-based auth, FCM v1 service account, WNS package/secret) and template registrations using platform-specific payload shapes, since a single logical notification (title, message, badge count) needs an entirely different JSON structure for APNS versus FCM, which the template's platform-specific body handles via the shared $(title)/$(message) placeholder substitution. authorizationRules with distinct rights combinations (Listen-only, Send-only, full Listen+Manage+Send) matter for credential hygiene: a backend service that only ever sends notifications should use the BackendSendOnly rule, not the DefaultFullSharedAccessSignature rule, since a Send-only credential leak can't be used to also manage or read the hub's registration data.

When to Use This Tool

•Maintaining separate platform-specific templates (one for apple with an aps-wrapped payload, one for fcmV1 with a message/notification-wrapped payload) using the same $(title)/$(message) placeholders, so application code sends one logical notification through the hub and each platform's registered devices receive it in their required native format.
•Using BackendSendOnly (rights: [Send] only) for a backend service's connection string, rather than the DefaultFullSharedAccessSignature rule, so a leaked backend credential can't also be used to manage hub configuration or read the full registration list.
•Tagging registrations with meaningful segments (prod, ios, premium-user) so a send operation can target a specific tag combination (like premium-user AND prod) rather than broadcasting to every registered device regardless of relevance.
•Choosing fcmV1 credentials (googleProjectId plus a service account JSON) rather than a legacy FCM server key, since Google has moved FCM authentication to the newer HTTP v1 API using service account-based auth, which fcmV1 in Notification Hubs specifically supports.

Pro Tips

TIP

Never use a full Listen+Manage+Send credential for a backend service that only needs to send, scope it to a Send-only rule, this is a cheap, high-value security improvement that limits the damage from an accidental credential leak.

TIP

Design registration tags deliberately as a real segmentation scheme (platform, environment, user tier) from the start, retrofitting a tagging strategy after devices have already registered without meaningful tags means you can't retroactively target historical registrations by a dimension they were never tagged with.

TIP

Verify you're using fcmV1 with service account credentials for new Android integrations, not a legacy FCM server key approach, since Google's platform direction has moved away from the older authentication method.

How It Works Under the Hood

The builder validates that namespaceName, hubName, resourceGroup, sku, platformCredentials, and registrations all resolve before accepting the JSON as a valid combined hub configuration; it can't verify the platform credentials (APNS certificate validity, FCM service account permissions, WNS package SID) are actually valid and currently active with each platform provider, those are only confirmed when the hub actually attempts to send a real push notification.

Frequently Asked Questions

Why do the APNS and FCM templates have such different JSON structures for what's conceptually the same notification?: Each push notification platform defines its own required payload schema, APNS wraps content under an aps key with alert/badge/sound fields, while FCM's v1 API wraps it under message.notification and message.data. Notification Hubs' templated registration approach lets application code send one logical payload with placeholders ($(title), $(message)) and have the hub apply each platform's own required structure automatically, rather than the sending application needing to construct platform-specific payloads itself.
What's the risk of using DefaultFullSharedAccessSignature everywhere instead of a scoped rule like BackendSendOnly?: The full rule grants Listen, Manage, and Send rights together, if a credential using that rule leaks (checked into a repo, exposed in a client app, logged accidentally), the leaked credential can be used not just to send notifications but to manage the hub's configuration and read registration data. A backend service that only ever needs to send notifications should use a Send-only scoped rule specifically to limit the blast radius of a potential credential leak.
Does googleProjectId plus serviceAccountJson replace the older FCM legacy server key approach?: Yes, this is the fcmV1 credential type specifically for Google's newer, service-account-based FCM HTTP v1 API, which is the direction Google has moved FCM authentication toward, replacing the older, simpler server key approach. If you're setting up a new Notification Hub integration with Android, fcmV1 with proper service account credentials is the current recommended path rather than a legacy server key configuration.

Related Learning Guides

Functions Hosting Plans22 min read
Service Bus vs Event Grid vs Event Hubs24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.