Integrate a partner Android app
A Kie.la mobile application does not handle authentication itself.
It delegates the full flow (silent code, PIN entry, validation on the Kie.la app)
installed on the phone.
Your app then receives an exchange token to send to your backend.
Reference implementation: restaurant module (la.kie.restaurant).
Compared to a classic mobile app
| Classic app | Kie.la partner app |
|---|---|
| Login screen (email / password, OAuth, SSO) | No login screen — Intent to the Kie.la app |
| Local token storage (JWT, refresh token) | Ephemeral exchange token, used once on the API side |
| WebView or proprietary auth SDK | Documented Intent contract (KieLaAuthContract) |
| OTP code displayed in the app | Code managed by the Kie.la app — never visible in the partner app |
| Optional user validation | Mandatory accept / reject sheet on the Kie.la app (same as web) |
Console prerequisites
module.exports = {
name: "myapp",
uuid: "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx",
};
- Register the application in the Console. Whether you ship a website, an Android app, or both is your product decision — it is not a platform field.
- Backend: proxy route POST /auth-proxy/api/verify (like kresto) or direct call to the auth service depending on your architecture.
Code to add in the Android app
-
Manifest — Kie.la package visibility (Android 11+):
<queries> <package android:name="la.kie.kapp" /> <intent> <action android:name="la.kie.kapp.action.AUTHENTICATE" /> </intent> <intent> <action android:name="la.kie.kapp.action.WARM_UP" /> </intent> </queries> -
Contract class (
KieLaAuthContract) — Intent constants aligned withKKieLaAuth(platform contract):ACTION=la.kie.kapp.action.AUTHENTICATEACTION_WARM_UP=la.kie.kapp.action.WARM_UP- Extras:
app_name,app_uuid,verify_url,parent_origin,profile_fields,app_label - Result:
exchange, oroutcome(accept/reject/timeout)
- BuildConfig: APP_NAME, APP_UUID, API base URL (BOOKING_BASE_URL or equivalent). The verify URL is usually {BASE}/auth-proxy/api/verify.
- Before auth: check that the Kie.la app is installed, call warm-up (~400 ms before launch) to start the socket service if the app was in the background.
-
Launch auth:
startActivityForResult( KieLaAuthContract.buildAuthIntent(context), REQUEST_KIVA_AUTH); -
In
onActivityResult: read EXTRA_EXCHANGE, then call your business API with exchange + parentOrigin (e.g. POST /api/reservations).
User flow
- The user fills in the business form in your app (date, quantity, etc.).
- On submit, your app opens the Kie.la app (PIN + validation).
- The user accepts or rejects on the Kie.la sheet.
- The Kie.la app returns
exchangeto your app. - Your backend verifies the token via Kie.la and executes the action (booking, payment, …).
The auth server records this connection as accepted, rejected or expired — there is no separate "automatic" counter anymore.
What not to do
- Duplicate the device code mechanism in the partner app.
- Display the 6-character code in your UI.
- Use a Kiva login WebView for the native Android flow.
- Skip warm-up if the Kie.la app was not already running.
Android starter project
Gradle archive ready to open in Android Studio: Intent contract (KieLaAuthContract), sample screen, POST /api/session call. Console values are placeholders to replace in build.gradle.kts.
Full reference with test certificate and lab URLs: Kie.la lab (APK).
Local development
- Install the Kie.la app and your partner app on the same device / emulator.
- Use the LAN IP of the dev server (e.g.
https://192.168.x.x:4006) — not an unresolvable hostname on the device. - Debug build: trust the Kie.la test CA certificate (network_security_config + raw certificate).
- kresto / your API and the auth service must be running.