Migrating from WebView to Native
If you're already live with the Hubby WebView, you're closer to a Native eSIM Integration than you might think. The two integrations share the same booking API, the same authentication, the same webhooks, and the same underlying eSIM infrastructure. The only difference is what your app does after a booking is created.
Frankly, the technical side of this migration is usually not the difficult part. The real work is in designing your native UI screens — the data meter, installation flow, package selection, and top-up experience. The API migration itself is minimal.
How Similar Are They?
Very. Here's the full picture:
| Concern | WebView | Native | Changes? |
|---|---|---|---|
| Create booking | POST /api/bookings | POST /api/bookings | Identical call |
| Authentication | HMAC-SHA256 | HMAC-SHA256 | No change |
external_user_id | Required on every booking | Required on every booking | No change |
| Package provisioning | Automatic | Automatic | No change |
| Multi-destination optimization | Automatic | Automatic | No change |
| Universal eSIM lifecycle | Managed by Hubby | Managed by Hubby | No change |
| Webhooks | Same events | Same events | No change |
| Traveler sees packages | Hubby WebView UI | Your native UI | You build it |
| eSIM installation | Hubby WebView guides | Your UI + /native/instructions | You build it |
| Data meter | Hubby WebView UI | Your UI + /native/user-dashboard | You build it |
| Top-up purchase | Hubby WebView store | Your UI + POST /api/bookings | You handle payment |
| Package activation | Automatic in WebView | POST /native/redeem-package | New call |
| Device compatibility | Handled by WebView | POST /native/device-compatibility | New call (optional) |
The entire backend integration — booking, auth, webhooks — stays the same. You're swapping out the frontend layer: instead of opening a WebView URL, you call a few /native/* endpoints and render the results yourself.
What You're Actually Changing
Removing: redirect tokens + WebView
In the WebView flow, after creating a booking your backend creates a redirect token (POST /api/redirect-tokens/create) and your app uses that token to open the Hubby WebView in an in-app browser. You can drop both of these.
Adding: three new endpoints
| Endpoint | Purpose | When to call |
|---|---|---|
GET /api/native/user-dashboard | Returns the full traveler state — eSIM, packages, queues, data usage | Every time the user opens the eSIM section |
POST /api/native/redeem-package | Activates a pending package onto the traveler's eSIM | When the user taps "Redeem" or "Activate" |
POST /api/native/instructions | Returns device-specific eSIM installation steps | When the user needs to install their eSIM |
Optional:
| Endpoint | Purpose |
|---|---|
POST /api/native/device-compatibility | Check if a specific device supports eSIM |
GET /api/native/device-compatibility | List all known compatible devices |
Adding: payment handling
In the WebView, Hubby manages the top-up purchase UI. In the Native integration, you are the Merchant of Record — you handle the payment in your app, then call POST /api/bookings to provision the package. Hubby provides B2B net rates and recommended B2C prices via the package catalog.
Migration Steps
1. Keep your bookings exactly as they are
Your existing POST /api/bookings calls already include external_user_id — that's required for both WebView and Native. Don't change anything about how you create bookings. The same booking endpoint, same payload, same response.
2. Build your native dashboard screen
Call GET /api/native/user-dashboard?external_user_id=... and render the traveler's state. This single endpoint returns everything: user info, eSIM credentials, package queues, active packages, and data usage. See the Native eSIM Integration guide for the full response structure and rendering logic.
3. Add package redemption
When a traveler has unredeemed package queues, call POST /api/native/redeem-package with the package_queue_id. The response includes the updated eSIM state so you can refresh the UI without a second dashboard call.
4. Add installation instructions
Call POST /api/native/instructions with the traveler's device info. Hubby returns branded, device-specific steps — no need to maintain installation content in your app. This endpoint adapts to the device model, OS version, eSIM state, and locale.
5. Handle top-up payments
Replace the WebView's built-in purchase flow with your own. When a traveler wants more data, process the payment through your PSP, then call POST /api/bookings with the same external_user_id. The new package queues onto their existing eSIM automatically.
6. Stop creating redirect tokens
Once your native screens are live, you no longer need POST /api/redirect-tokens/create. Remove the redirect token creation and the WebView open from your app.
Mixing WebView and Native
You don't have to migrate everything at once. WebView and Native can coexist for the same partner — they share the same external_user_id and the same booking infrastructure. Common patterns:
- Native data meter, WebView for everything else — move only the most-viewed screen to native while keeping the rest in the WebView
- Native for returning travelers, WebView for new users — new users get the guided WebView experience; returning users get the faster native flow
- Gradual rollout — build native screens for a subset of users while keeping the WebView as the fallback
The decision is entirely in your app's UI layer. You can switch individual users between WebView and Native at any time.
Related
- Native eSIM Integration guide — complete native flow reference
- Hubby WebView guide — complete WebView flow reference
- Authentication guide — HMAC-SHA256 setup (same for both)
- Webhooks — event catalog (shared across both integration modes)