Push notifications (your app)
Lodgestory CRM › Settings → Connections → Push notifications
Connect your own iOS and Android app as a channel and send real push notifications — booking updates and offers — from campaigns, automations or one API call.
TL;DR
- What it is — a channel for the app you publish. Upload your Apple push key and Firebase service account once, drop two reference files into the app, and Lodgestory sends through your credentials: image, up to three buttons, a deep link, a live countdown on Android.
- Who it's for — Account Owners and Admins connect the app and manage credentials; your developers integrate it (no SDK, reference code provided); marketing and operations send.
- Top outcome — a guest who installed your app hears from you the moment it matters, and every send, delivery and tap is recorded on their contact — the same one you message on WhatsApp.
This is about notifications to your customers' phones through your app. Notifications to your own team (new messages, assignments) are Push Notifications.
At a glance
| Plan tiers | All paid tiers. |
| Who can use it | Admins and Account Owners connect, upload credentials, rotate keys and flag test devices. Any member sees the page; any member sends (campaigns, contact panel). |
| Channel relationship | A push app is a channel like WhatsApp or Email: it appears in the campaign builder, the Send push automation action, the contact panel, webhooks and the API. It is outbound only — nobody replies to a push. |
| What delivers | Apple (APNs) and Google (FCM) with your credentials. Lodgestory stores them encrypted and never shows them again. |
| Top limits | One channel per app (one iOS bundle id + one Android application id). 4 KB per notification, 3 buttons, title 120 characters, body 1,000. Promotional pushes: opt-in required, quiet hours and a daily cap per device (both editable). |
| API | Yes — Push notifications API and MCP tools. |
How to find it
Settings → Connections → the Push notifications card → Add app, or open an existing app from the channel list.
Connect an app
- Name, bundle id, application id. The iOS bundle id (e.g.
com.example.app) is what Apple delivers to — it must match the build exactly. The Android application id is informational. - APNs key. In Apple Developer → Keys, create (or reuse) a key with Apple Push Notifications service enabled and download
AuthKey_XXXXXXXXXX.p8(Apple shows it once). Upload the file, the Key ID and your Team ID. Apple now issues keys per environment: the production key is what App Store and TestFlight builds use; add a development key only if you also test with Xcode-run builds. Lodgestory validates the key against Apple immediately — key and team accepted for that environment, or the exact reason (wrong environment, revoked key…). Apple checks the bundle id only on a real send, so finish with Send a test to one of your phones. - Firebase service account. In the Firebase console → Project settings → Service accounts → Generate new private key. Upload the JSON. Lodgestory runs a dry-run send to check the key, that the Cloud Messaging API (V1) is enabled and that the account may send (
cloudmessaging.messages.create). - Publishable key and secret. The publishable key (
pk_…) goes inside the app — it can only register and update the app's own devices. The channel secret is shown once; your backend needs it only if it signs contact tokens itself (minting them through the API needs no secret). Rotate either here. A new publishable key replaces the old one at once: installed apps keep receiving pushes, but they cannot register new tokens, change opt-ins or log out until you ship an app update with the new key — so rotate it only if it leaked. A new secret makes unused contact tokens invalid. - Integration. The Integration tab holds the reference code with your values filled in: a backend quickstart (curl),
LsPushMessagingService.kt+ manifest excerpt for Android,AppDelegate+Push.swiftandNotificationService.swiftfor iOS, andlodgestoryPush.tsfor apps built with Expo. Hand the tab to your developers; the contract is also documented in the API reference.
Apps built with Expo need none of the keys above: they register their Expo push token, and Expo sends with the Apple and Firebase credentials in your EAS project. The Expo push card shows how many devices use it and takes an Expo access token only if your Expo project has enhanced push security switched on (Add an access token; validation reads a receipt from Expo, nothing is sent). Pushes reach Expo apps without buttons, and a countdown becomes text. The reference module for Expo apps is on the Integration tab (Expo app (React Native)).
Disconnected apps. Suspending the organisation disconnects its push apps: devices cannot register and nothing is sent, including queued campaigns. Once access is restored, an admin opens the app and clicks Reconnect — keys, devices and the publishable key are kept, so installed apps need no update.
Deleting an app (the danger zone at the bottom of its page) permanently erases its devices, credentials, push history and delivery logs, and every campaign sent through it. Contacts stay.
Readiness shows per platform: iOS ready needs the bundle id and a validated production key; Android ready needs a validated service account; Expo ready appears once the app has Expo devices or an access token, and turns to needs attention when Expo reports a credential problem. A credential Apple or Google rejects while sending shows up here too, with the reason.
Devices and test devices
The Devices tab lists registered installs — platform, app version, opt-in, status (Active, Invalid when the token died, Unsubscribed), the contact they are linked to and the last six characters of the token. Nobody can see the token itself.
Flag your own phones as test devices (install the app, register, then Mark as test device). Send test push on this page and to: { testDevices: true } in the API send to them — every device of a flagged person, or the flagged install alone while it is not linked to anyone (before login, after logout) — bypassing the promotional gates, so you can try images, buttons and countdowns before a campaign. The result covers every test device.
For your developers. The chevron on a device row opens its delivery log: the last pushes to that phone with Apple's / Google's answer (sent, failed with the error code, invalid device) and the delivered / opened beacons the app posted, with timestamps — a way to check one phone end to end without hunting for message ids. The result of Send a test carries What the phone receives: the exact JSON for Android (FCM), iPhone (APNs) and iPhone via Firebase, so the Kotlin and Swift parsing can be checked against the real keys. The API offers both too: dryRun: true on a send returns the preview, and GET …/devices/{deviceId}/deliveries returns the log.
Promotional rules
Transactional pushes (booking confirmed, check-in ready) reach every active device. Promotional pushes reach only devices whose person opted in inside the app, outside quiet hours (default 21:00–09:00 in the device's time zone; the fallback time zone applies when the app did not report one), and under the daily cap (default 2 per device per 24 hours). All three are editable here. A promotional campaign that runs into quiet hours waits for them to end. The Android channel ids (transactional / promotional) let users mute offers on their phone without losing booking updates — the reference code creates both.
Apple's App Store Review Guideline 4.5.4 and Google Play's policies require explicit opt-in (consent wording shown in the app) and an in-app opt-out for promotional push and forbid sensitive data in notifications; the opt-in state the app reports is what Lodgestory enforces. Apple also forbids the Time Sensitive level for marketing, so it is offered for transactional pushes only.
Sending
- Campaigns — pick the push app as the channel in the campaign builder; compose title, body, image, deep link, buttons, countdown, choose transactional or promotional; the funnel counts sent, delivered and opened per recipient.
- One guest — the Send push action in the contact panel (shown in every workspace that has a push app; clicking it checks the person's devices, so opening a chat costs nothing — a person without an active device gets "No device registered" instead of the composer; with several apps you pick which one sends), or
POST /api/wp-crm/push/{organisationId}/send. - Automations — the Send push action on any trigger (a booking confirmed, a lead stage reached…).
Pushes never appear in the inbox — a push is not a conversation. Each one shows under the guest's Recent pushes in the contact panel (loaded when you open it: title, when, how far it got — sent, delivered, opened — and which campaign, automation or agent sent it) and in the campaign or message status with per-device outcomes.
Troubleshooting
| You see | Why | Do |
|---|---|---|
| No eligible device on a send | The person has no registered, active device — or no opt-in for a promotional push | Check the Devices tab for the contact; ask your developers whether the app identified the device after login |
| Devices flip to Invalid | Apple/Google reported the token dead: the app was uninstalled or the token rotated | Nothing — the app re-registers on next launch and the device is active again |
| Credentials rejected on the channel | The key was revoked or the Cloud Messaging API disabled | Upload a fresh key / enable the API, then Validate |
| iOS shows text but no image or buttons | The app has no Notification Service Extension | Add the extension from the Integration tab |
| Android pushes arrive late or not at all on some phones | The phone maker's battery optimiser | Transactional pushes already go at high priority; ask the guest to exempt the app from battery optimisation (Xiaomi, Vivo, Oppo) |
Related pages
Updated about 1 hour ago
