Notifications & Events

The notification lifecycle

Once you set a travel context, the notification moves through a simple lifecycle — and the SDK tells you about every step through events:

1. Scheduled. The SDK accepts the trip and queues one notification for it. A newer travel context replaces the pending one.
2. Delivered. After the user leaves your app and the Stay22-managed delay elapses, the notification is shown.
3. Opened. The user taps it and lands in a curated booking experience for their destination and dates, attributed to your aid.
4. Skipped or cancelled. If conditions aren't right — the user is still in the app, the destination is their home city, a cooldown is active, permission is missing — the SDK holds back and emits the reason instead.

Customize the notification

The default copy works out of the box, but you can match it to your app's voice with notificationConfig. Set it once, any time after initialization:

import com.stay22.sdk.NotificationConfig
import com.stay22.sdk.NotificationInterruptionLevel

Stay22.notificationConfig = NotificationConfig(
    title = "Hotels in {destination}",
    subtitle = "{checkin} - {checkout}",
    message = "Tap to find the best deals nearby",
    categoryId = "stay22_destinations",
    threadId = "stay22",
    interruptionLevel = NotificationInterruptionLevel.active
)

Stay22.notificationConfig = NotificationConfig(
    title: "Hotels in {destination}",
    subtitle: "{checkin}-{checkout}",
    message: "Find stays near {destination}.",
    categoryId: "stay22_destinations",
    threadId: "stay22",
    badge: 1,
    interruptionLevel: .active,
    relevanceScore: 0.8
)

Text placeholders

Title, subtitle, and message support placeholders that the SDK fills in from the travel context:

Attribution

Bookings are attributed to the aid you initialized with. To segment where conversions come from — much like campaign on Allez links — set an optional campaign ID:

Stay22.campaignId = "spring_push"

Stay22.campaignId = "spring_push"

Events

The SDK emits an event for every decision it makes, which is the best window into what it's doing — wire them into your analytics or logging:

import com.stay22.sdk.Stay22Event

Stay22.advanced.setEventHandler { event ->
    when (event) {
        is Stay22Event.NotificationScheduled -> log("scheduled: ${event.destination}")
        is Stay22Event.NotificationClicked -> log("clicked: ${event.destination}")
        is Stay22Event.NotificationSkipped -> log("skipped: ${event.reason}")
        else -> Unit
    }
}

Stay22.advanced.setEventHandler { event in
    switch event {
    case .notificationScheduled(let destination, let delay):
        print("scheduled: \(destination), delay=\(delay)s")
    case .notificationClicked(let destination, let url):
        print("clicked: \(destination), \(url)")
    case .notificationSkipped(let reason):
        print("skipped: \(reason)")
    default:
        break
    }
}

Skip and block reasons

When the SDK holds back, the reason tells you why — most are expected behavior, not errors:

Manual scheduling

By default the SDK schedules automatically when a travel context is set. If you want to control the trigger yourself — for example, only after checkout of a flight purchase — run the same pipeline manually:

Stay22.advanced.scheduleNotification()

Stay22.advanced.scheduleNotification()

All the same relevance checks still apply — manual scheduling triggers the pipeline, it doesn't bypass it.