Accounts and manufacturer scope

Platform-registered application identity

Each partner app uses a registered clientId. The platform maps it to a fixed manufacturer and enables its services. Set Configuration.clientId on Android or use configureWithConsent:clientId:paymentScheme: on iOS. Do not retain the default official-app identity.

manufacturerId is a server-issued business scope, not an authorization parameter the host may choose. Editing request headers or hiding other manufacturers in the UI cannot replace server enforcement.

Platform login and sessions

The host calls the agreed platform login and verification APIs. Include X-App-Client: <registeredClientId> on login requests. The SDK adds this header to its own requests; the host must add it to requests it sends directly.

Pass the login response unchanged to the SDK. A session contains:

The SDK validates and securely stores the session. Fabricating JSON fields does not grant platform access. Partner tokens cannot replace platform tokens. This version does not provide partner account token exchange.

Two application scopes

Creating an order still requires an explicit vehicleId and bindingVersion. A mismatched vehicle cannot switch a manufacturer app’s scope. Orders are constrained by both account and application scope. Use server values for prices, inventory and allowed actions.

Unknown or disabled apps cannot log in. Removing X-App-Client or substituting the official identifier cannot expand a manufacturer session’s scope. Before delivery, have the platform confirm application registration, manufacturer mapping and enabled services.

Session changes and logout

When the account or token changes, cancel old cloud operations, wait for settlement, install the new session and recreate vehicle and commerce clients. Clear old vehicle, order and address UI state so stale results cannot appear under the new account.

Use the SDK’s clearSession or account.clear on logout; do not manipulate secure storage directly. The SDK owns pending binding, unbinding and payment records. Run recovery when the original account signs in again.

Vehicle caches and cloud recovery records are isolated by API base, clientId and account. Token refresh does not change their ownership. Terminal credentials retain account/terminal scope, so test and production still require separate installation identities and storage.

When upgrading from 0.2.0 or earlier, legacy records have no saved API/clientId origin. Unclaimed pending records return LEGACY_SCOPE_REQUIRED. Verify the origin from the original installation configuration, then call adoptLegacy with an empty object under the original account, API base and clientId. Call recover after it succeeds. Never automatically claim records for an arbitrary current environment or delete them to bypass the error. LEGACY_SCOPE_CONFLICT means another origin already owns them; return to that origin. Legacy records are retained, and completed records are not replayed.

Application identity security boundary

clientId is public and may appear in the binary. It does not prove a request came from an authentic installation. This version does not integrate App Attest, Play Integrity or package signature verification. Arrange application attestation separately if your partnership requires those guarantees; a public identifier is not a secret key.

Do not put platform management keys, device credentials or signed payment parameters in frontend configuration, logs or analytics. The SDK invokes payment; the server confirms the financial state of the order.

Android: install the login response, then create a client

Complete Android configuration with the registered clientId and privacy consent first. Call on the main thread with the original platform login response and agreed API base. setSession is synchronous and throws for invalid configuration/session data. The host handles the error, keeps business UI closed until success, and does not log the JSON or credentials from exceptions.

import android.content.Context
import net.oou.mobile.CloudVehicles
import net.oou.mobile.MobileSdk

fun installVehicleSession(
    context: Context,
    platformSessionJson: String,
    apiBase: String,
    language: String
): CloudVehicles {
    MobileSdk.setSession(context, platformSessionJson)
    return MobileSdk.vehicles(context, apiBase, language)
}

iOS: continue after session installation succeeds

After iOS initialization, call on the main thread. Create the client and start recovery only in the success branch. The host provides ready and failure; keep business entry points closed on failure.

#import <InfiniteRideMobile/InfiniteRideMobile.h>

void InstallVehicleSession(NSString *sessionJSON, NSString *apiBase,
                           NSString *language,
                           void (^ready)(IRCloudVehicles *), IRReject failure) {
    [[IRMobileSDK account] write:sessionJSON resolve:^(id value) {
        IRCloudVehicles *vehicles = [[IRCloudVehicles alloc]
            initWithBaseURL:apiBase language:language];
        ready(vehicles);
    } reject:failure];
}