Your app already knows where they are going.
The Stay22 Mobile SDK turns travel intent in your app into well-timed accommodation offers — one local notification per trip, one curated booking experience, every booking attributed to you.
A revenue line built on intent you already collect.
Your users already tell your app where they’re going — they book a flight, save an event, search a destination. That signal expires quietly today. Passed to the SDK with a single call, it becomes a new revenue stream: one well-timed notification, a curated booking experience, and affiliate revenue attributed to your partner ID.
You install the SDK and tell it about the trip. Stay22 handles timing, relevance, and the booking experience.
Every booking is attributed to your partner ID (aid) and earns you affiliate revenue.
Destination, dates, places — whatever you have, sent with a single method.
- 01
A traveler drops signals in your app — searches a destination, picks dates, saves a place.
- 02
You pass those signals to the SDK with a single call.
- 03
The SDK waits for exactly the right moment, then shows one notification for that trip.
- 04
One tap drops the traveler into a curated booking experience for their destination and dates.
- 05
Every booking is attributed to your partner ID and earns you affiliate revenue.
One notification, well timed.
The SDK is deliberately conservative — a spammy notification costs you user trust, so it only shows one when it’s worth showing.
Setting a new travel context replaces any pending notification; it never stacks.
Delivery waits until the user has left your app, after a delay tuned by Stay22.
If the destination looks like home — the user’s own city, or anywhere within a configurable suppression range — no notification is shown.
A cooldown prevents users from being notified too often, even across multiple trips.
Everything the user sees is yours to shape — title, message, grouping, badges, action buttons — with {destination} and date placeholders filled in per trip.
Notification timing, delays, frequency caps, and the local suppression range are managed by Stay22 per partner — you don’t configure them in code. Reach out to your account manager to tune them.
Already have push infrastructure? Send from it, book through us.
Take the SDK if you can — it decides when to send, holds back trips that look like home, caps how often a user hears from you, and ships the booking screen. That is the hard part. But if adding a binary isn’t on the table, the same intent still converts: send your own push, point it at an Allez link.
Free, no API key, no backend. Tag every push with campaign and your reporting separates push-driven bookings from everything else — it repeats, so one send can carry a channel and a cohort. And keep medium=pushnotif_manual — that is what marks these as your sends, not ours.
Either route earns you commission. The difference is who carries the hard part — when to send, when to stay quiet, and what the traveler sees next.
That is the SDK’s whole job.
iOS
- Minimum
- iOS 15.0
- Language
- Swift 5.9+
- Distribution
- Swift Package Manager
Ships an Apple privacy manifest and has no third-party dependencies.
stay22-ios-sdk →Android
- Minimum
- Android 8.0 (API 26)
- Language
- Kotlin
- Distribution
- Maven — com.stay22:sdk
Prebuilt binary, distributed through a public GitHub repository.
stay22-android-sdk →Let’s see what your travel intent is worth.
Tell us about your app and audience, and we’ll set up your partner ID, tune notification timing for your account, and get you into the SDK.