Mobile

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",
};

Code to add in the Android app

  1. 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>
  2. Contract class (KieLaAuthContract) — Intent constants aligned with KKieLaAuth (platform contract):
    • ACTION = la.kie.kapp.action.AUTHENTICATE
    • ACTION_WARM_UP = la.kie.kapp.action.WARM_UP
    • Extras: app_name, app_uuid, verify_url, parent_origin, profile_fields, app_label
    • Result: exchange, or outcome (accept / reject / timeout)
  3. BuildConfig: APP_NAME, APP_UUID, API base URL (BOOKING_BASE_URL or equivalent). The verify URL is usually {BASE}/auth-proxy/api/verify.
  4. 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.
  5. Launch auth:
    startActivityForResult(
        KieLaAuthContract.buildAuthIntent(context),
        REQUEST_KIVA_AUTH);
  6. In onActivityResult: read EXTRA_EXCHANGE, then call your business API with exchange + parentOrigin (e.g. POST /api/reservations).

User flow

  1. The user fills in the business form in your app (date, quantity, etc.).
  2. On submit, your app opens the Kie.la app (PIN + validation).
  3. The user accepts or rejects on the Kie.la sheet.
  4. The Kie.la app returns exchange to your app.
  5. 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

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.

Download Android starter

Full reference with test certificate and lab URLs: Kie.la lab (APK).

Local development

See also