SDK Overview

Sendrealm has two kinds of SDKs:

• Mobile SDKs run inside user devices and register push tokens.
• Server SDKs run in trusted backend or edge environments and call the Sendrealm public API.

Pick the SDK based on where your code runs and what you need to do.

​

Which SDK Should I Use?

Expo Go is not supported for mobile push because Sendrealm uses custom native Android and iOS code. Use a development build when working with Expo.

​

Mobile SDKs vs JavaScript SDK

Mobile SDKs answer this question:

Which device can receive a push notification?

They create or restore a Sendrealm device ID, get the native push token from Firebase or APNs, register that token with Sendrealm, track notification lifecycle events, and expose client-side helpers such as permission prompts, tags, and device events. The JavaScript SDK answers this question:

How does my trusted backend call the Sendrealm API?

It sends emails, ingests events, manages contacts, sends push notifications, and performs other API operations with a Sendrealm API key.

​

Mobile Push Setup In One Picture

For Android:

1. Sendrealm stores your Firebase service account JSON.
2. Your Android app initializes the Sendrealm SDK.
3. Firebase Cloud Messaging gives the app an FCM token.
4. The SDK registers the token with Sendrealm.
5. Sendrealm sends push through Firebase.

For iOS:

1. Sendrealm stores your APNs .p8 key, Key ID, Team ID, Bundle ID, and environment.
2. Your iOS app initializes the Sendrealm SDK.
3. iOS gives the app an APNs token.
4. The app forwards that token to the SDK.
5. The SDK registers the token with Sendrealm.
6. Sendrealm sends push through APNs.

​

Recommended Setup Order

For a mobile app, use this order:

1. Configure provider credentials in Sendrealm.
2. Install the correct mobile SDK.
3. Initialize the SDK.
4. Request notification permission after explaining the value to the user.
5. Link the device to the signed-in user with login.
6. Add tags or custom events only after initialization.
7. Send test notifications on real target devices.
8. Check diagnostics before debugging dashboard campaigns.

This order prevents the most common setup confusion: the dashboard can be configured correctly while the app still has no registered device token, or the app can register a token while Sendrealm still lacks provider credentials.

​

What You Need From The Dashboard

Mobile SDKs need a Sendrealm app ID. You pass this app ID to initialize. Server SDKs need a Sendrealm API key. You pass this API key to the JavaScript SDK or store it in SENDREALM_API_KEY. Push provider credentials are uploaded to Sendrealm:

• Firebase service account JSON for Android.
• APNs .p8 key and Apple identifiers for iOS.

See Mobile Push Credentials for the full credential walkthrough.

​

Delivery Timing And Device Behavior

Push notifications are not guaranteed to appear instantly on every device. Sendrealm can accept and send the notification request, and Firebase or APNs can accept it for delivery, but the final delivery and display behavior still depends on the device, operating system, user settings, battery state, app state, and platform policies. For Android, Firebase Cloud Messaging delivery is affected by message priority and Android power management. Normal-priority messages can be delayed while the device is in Doze mode. High-priority messages are intended for time-sensitive, user-visible notifications, but overusing high priority can cause delivery behavior to be adjusted by FCM. For iOS, APNs delivery depends on APNs priority, device connectivity, notification settings, Focus modes, and iOS background execution policy. Background update notifications are low priority and may be throttled. Some low-priority notifications can be grouped, delayed, or not delivered. Design push as a best-effort user communication channel:

• Use high priority only for urgent, user-visible Android notifications.
• Do not rely on silent or background pushes for critical user-visible work.
• Keep notification payload processing fast.
• Expect some messages to be delayed, dropped, collapsed, throttled, or hidden by user settings.
• Always keep important state available when the user opens the app.

​

What Success Looks Like

After setup, you should be able to confirm:

• Mobile SDK initialization succeeds.
• Diagnostics show a device ID.
• Diagnostics show token presence.
• Permission status matches what the user chose.
• The device is subscribed unless the user opted out.
• Android package name matches Firebase.
• iOS Bundle ID and APNs environment match the build.
• A foreground test push arrives.
• A background test push arrives.
• Tapping a push opens the expected screen or URL.

​

Where To Go Next

• Start with Mobile Push Credentials if you have not uploaded Firebase or APNs credentials yet.
• Use Android SDK for a native Android implementation.
• Use iOS SDK for a native Swift implementation.
• Use React Native Bare SDK for React Native CLI apps.
• Use React Native Expo SDK for Expo development builds.
• Use JavaScript SDK for backend API calls.