search

Found

info Overview

Generate FCM (HTTP v1) and APNs push notification payloads side-by-side. Supports badge, sound, and custom data fields — copy-ready JSON, no upload.

📘 How to Use

  1. Enter the title, body, and badge count
  2. Set the sound toggle and add custom key-value data fields
  3. Review the generated FCM and APNs JSON payloads

Push Notification JSON Payload Builder (FCM / APNs)

Copied!
Copied!
Article

Push Notification JSON Payload Builder for FCM and APNs

Build test payloads for mobile push notifications in both Firebase Cloud Messaging (FCM HTTP v1) and Apple Push Notification service (APNs) formats side-by-side. Enter the title, body, badge count, sound flag, and any custom key-value data in one form, then copy the resulting JSON straight into Postman, curl, or your backend code. Useful when validating notification structure before wiring up the Firebase Admin SDK or the APNs HTTP/2 endpoint.

💡 About this tool

FCM and APNs encode the same notification using different JSON shapes. FCM HTTP v1 places common fields under message.notification.title/body, ships custom data as message.data (string values only), and exposes per-platform overrides under message.android.notification and message.apns.payload.aps. The standalone APNs payload nests the alert under aps.alert.title/body, sits badge and sound directly inside aps, and expects custom data at the root level — outside the aps dictionary. Moving between the two formats by hand is easy to get wrong, so this builder shows both layouts at once from a single input.

🧐 Frequently asked questions

Q: Is the output compatible with FCM's legacy /fcm/send API? A: No. This tool emits payloads matching the FCM HTTP v1 endpoint (https://fcm.googleapis.com/v1/projects/{project}/messages:send). Legacy FCM endpoints were deprecated in June 2024 and the response shape, authentication, and message wrapper all changed in v1.

Q: Can custom data values be numbers or nested JSON objects? A: The tool emits all custom values as strings. FCM HTTP v1 requires data map values to be strings, so passing numbers or nested objects there returns a 400. APNs at the root level is more lenient, but cross-platform code paths usually keep everything as strings for symmetry.

Q: Can aps.sound be set to a custom sound file? A: The toggle here emits "sound": "default". To use a custom .caf filename bundled in the app, copy the JSON and replace "default" with the filename. For critical alerts, replace the string with the {name, critical, volume} dictionary form documented in the APNs payload spec.

Q: What's the difference between leaving badge empty and setting it to 0? A: Leaving it empty omits the badge field entirely, so the existing app badge is unchanged. Sending "badge": 0 explicitly clears the badge — useful when the user has read the messages and you want to reset the dot. Add the 0 by hand after copying if you need that behavior.

Q: Can the generated JSON be sent as-is? A: The payload structure is spec-compliant, but you still need to attach an OAuth 2.0 bearer token for FCM v1 or a JWT-based APNs auth header plus a device token before sending. The tool only generates the body — not the transport.

📚 Migrating from FCM legacy /fcm/send to HTTP v1

Teams still on FCM legacy need to migrate to HTTP v1 since the older endpoint was retired in June 2024. The wire format change is significant. Legacy used a flat {to, notification, data} envelope; v1 wraps everything in {message: {...}} with explicit per-platform sections. Authentication moves from a static server key (long-lived API key) to short-lived OAuth 2.0 access tokens minted from a service account JSON, which means backends need to refresh tokens every hour and store credentials differently.

The data-vs-notification split also tightened in v1. In legacy mode, sending only data to a backgrounded iOS app sometimes still showed a system notification depending on the client SDK version; in v1 the rules are explicit — notification triggers display by the system, data is delivered silently to the app's foreground handler. If you relied on the legacy ambiguity, your migration likely needs both fields populated or a content-available: 1 flag in the APNs override.

For raw cross-checking against the APNs HTTP/2 endpoint, this tool's right-hand APNs panel matches what Apple's Notification Server expects when you post directly to https://api.push.apple.com/3/device/{device-token}. Comparing the two outputs side-by-side helps catch cases where a custom data key needs to move from message.data (FCM) to root level (APNs direct), or where android.notification.notification_count should match aps.badge across platforms.