Sign in. Ask permission. Save data.

Exact contracts, permissions and API evolution

Read the full profile and data contracts, null/error semantics, cross-platform patterns, security requirements and verification matrix. Future app metadata, legal documents, organisation and moderation methods are clearly labelled as proposals.

Understand the platform

A guided tour of ONE and Client

ExtremeX Client is your developer workspace: register applications, configure credentials and define the data they request. ExtremeX ONE owns the user’s identity, sign-in, consent and isolated app data. The SDK connects your application to those services.

The callback carries a short-lived code and state. The SDK checks the callback and state, exchanges the code using its saved PKCE verifier, and then requests the allowed profile. Data requests use the resulting bearer token; they do not send the user’s ONE password.

The tab names above match the current Client UI. Team permissions may hide controls that your account cannot use.

Shared setup · every platform

Register and configure your application

Complete these steps once for the application you are integrating. The language-specific guide below assumes this registration already exists.

1. Sign in to Client and choose a workspace

   Open Dashboard and sign in with ONE. On first use, claim your company’s reverse-domain namespace, such as com.example. Choose the workspace that should own this application.

   Expected result: you can create an app under the intended namespace. Existing team permissions determine which controls are available.

2. Create the app and select its type

   Use a service name such as myapp or app.myapp and a recognizable display name. The namespace and service produce APP_ID=com.example.myapp. Choose Public client for native, desktop, React Native or browser-only apps. Choose Web app for a backend that can keep a secret, and provide its HTTPS callback.

   Why: app type determines how token exchange authenticates the client. Public clients use S256 PKCE; confidential web servers also use CLIENT_SECRET.

3. Define the profile fields and permissions

   Open Data access. Select the ONE identity fields your app needs, explain their purpose and choose required or optional. Enable App data for the data examples. Enable Stay signed in to receive rotating refresh tokens.

   Expected result: the consent screen shows these fields and reasons. Optional fields may be declined, so your app must handle their absence.

4. Declare your first app-data keys

   Open Create data. Add theme with type string and high_score with type number. Save the schema. These keys belong to your app; they are separate from ONE profile fields.

   Expected result: writes to declared keys are type-checked. Declaring a key does not initialize a value; it stays absent until your app writes it.

5. Copy the public configuration and register the callback

   Open Credentials. Copy APP_ID and CLIENT_ID. Follow the credential table and your platform’s callback instructions below. Use the automatic native relay for the supplied Android/Apple clients, the direct custom callback for React Native AppAuth, or your registered HTTPS callback for a website/backend.

   Expected result: the URL used by your SDK matches an entry in Client exactly. Keep CLIENT_SECRET on confidential backends only.

Native apps default to https://client.extremextechnology.com/callback/APP_ID, which opens APP_ID://callback. Browser-only apps must register their own HTTPS callback as an additional redirect and set both redirectUri and callbackUri to it.

Read the ONE profile safely

1. Request access. In Client → Data access, select the fields your app needs and explain why. Age and birthday checks use the existing date_of_birth permission identifier, but its value is never returned.
2. Ask the user. Sign in through ONE and let the user review access. Optional fields can be denied. Do not interpret denial as false.
3. Read after sign-in. Use one.auth.data helpers. Each call reads current consent. Use a worker/coroutine or callback on UI platforms.
4. Handle three results. True means the check passed; false means the known value did not pass; null means missing or ungranted data. A revoked session, ban or network failure is an error, not a null result.
5. Complete missing fields. For granted-but-missing fields, the SDK opens or offers ONE’s existing completion view. Save in ONE, return to your app, then call the helper again. A denied field never triggers this prompt.

Name and address arrays preserve their positions with null for an unavailable component. Country values are the saved ISO country code, or OTHER. Age thresholds use the saved date, regardless of verification; combine a threshold with isUserAgeVarified() when your app needs a verified age. No helper returns a birth date or exact age.

Verify age when requested

When isUserAgeVarified() returns false, the supplied UI offers a “Verify your age” dialog linking to https://one.extremextechnology.com/account. Open Age verification in ONE, complete the ID and face checks, return, then retry the helper. The dialog is offered once per SDK client session; null or denied access never opens an age-verification prompt. Missing permitted data still opens the completion prompt first.

Bitmap types by platform

Android returns Bitmap; iOS returns UIImage; macOS returns NSImage; browsers return ImageBitmap; Go returns image.RGBA. Java returns AvatarBitmap with width, height and ARGB pixels. KMP, Python, Ruby, Rust, Node and React Native return a decoded RGBA bitmap with width, height and pixel bytes. Adapt those pixels to your UI toolkit. No additional profile image files are stored by ONE.

Connect a completion prompt to your UI

Browser, Android and Apple clients include a prompt. Android apps should call one.attach(activity) after activity recreation. The supplied Swing and Tkinter views install their prompt handlers; Compose installs its handler while OneLoginView is mounted. React Native’s createNativeClient installs an Alert prompt. For headless clients or custom layouts, use the following hooks and open the supplied ONE URL after the user chooses to continue:

• Java: one.auth.data.onMissingData; KMP: one.auth.data.onMissingData; Swift: one.auth.data.onMissingData.
• JavaScript: createClient({onMissingData: (event) => …}) or one.auth.data.setMissingDataHandler(handler).
• Python/Ruby: one.auth.data.on_missing_data; Go: one.Auth.Data.OnMissingData; Rust: one.on_missing_data.

Headless server code returns null and does not open a desktop browser. Forward the completion event through your authenticated UI, or provide your own dialog. For the age-verification action, the same handler receives fields ["age_verification"] and the fixed account URL; show “Verify your age” instead of a missing-data message. Handlers otherwise receive the missing fields and completion URL; JavaScript receives an event object with fields and url. JVM callbacks run on a worker; dispatch UI updates to the UI thread.

val legal: Boolean? = one.auth.data.isUserLegal()
val verified: Boolean? = one.auth.data.isUserAgeVarified()
when {
    legal == null || verified == null -> showMissingOrDeniedState()
    legal && verified -> continueWithVerifiedAdult()
    else -> showAgeRequirement()
}
val phone = one.auth.data.getPhoneNumber() // ["44", "7911123456"] or null
// The three UI functions above belong to your app.

Upgrade from SDK 1.x or 2.x

The generic one.auth.data.get and the old isUserVarified alias are removed. Use getName(), getEmail(), or another helper from the table. Sign-in/session support remains available for the login views. Use one.auth.signOut() to end the app session. Install version 3.2.0 using your platform’s normal install command below. Recompile and handle nullable flags: Java Boolean, Kotlin Boolean?, Swift/Objective-C NSNumber?, Go *bool, Rust Option<bool>, and null/None/nil in dynamic languages. Swift uses number.boolValue after unwrapping. Older release files remain available, but raw birth dates are removed from the server for every SDK version.

Go exports GetName/IsUserTeen and the other helpers with capitals; Rust uses get_name/is_user_teen and snake_case equivalents. Other platforms keep the spellings shown in the table, including Varified for compatibility.

How login, consent and views fit together

The Android library includes loginView and showLoginDialog. The source bundle includes SwiftUI, UIKit, Compose Multiplatform, React Native, Swing, Tkinter and browser views. Mount a layout or present it as a dialog/sheet.

1. Login: the control opens ONE in the system authentication browser. “Create an account” opens one.extremextechnology.com/signup.
2. Allow data access: ONE shows the app’s name, requested fields, reasons and required/optional choices. The user can decline optional fields or cancel.
3. Add missing data: selected fields missing from the ONE profile are collected before consent. The user saves, reviews the request again, then allows access.

These consent and completion views are hosted by ONE and shared across platforms. They are opened by the library’s auth session; apps never collect the user’s ONE password or imitate the consent decision locally.

<uses-permission android:name="android.permission.INTERNET" />
<!-- On your callback Activity (deliver onCreate and onNewIntent to the SDK): -->
<activity android:name=".MainActivity" android:exported="true"
          android:launchMode="singleTask">
  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="YOUR_CUSTOM_URI_SCHEME" android:host="callback" />
  </intent-filter>
</activity>

Understand app data and sessions

data.set(key, value), data.get(key), data.rep(key, value) and data.del(key) operate on the signed-in user’s data within your app’s namespace. Declared types are checked by ONE. Access requires the user’s current App data consent.

Accepted values: JSON strings, numbers, booleans, null, arrays and objects. Values are compressed with DEFLATE, then encrypted with AES-256-GCM. Existing encrypted records remain readable. Limits: 16 KiB of uncompressed UTF-8 JSON per value, 100 keys per write, 20 levels of nesting, and a 1.7 MB request body.

No file-upload or media-storage API is provided. Multipart uploads, data URLs, recognizable encoded files and binary byte arrays are rejected. Do not encode videos, images or files into data fields. The only image-upload exception is the user’s ONE profile photo.

Tokens last one hour; optional Stay signed in enables rotating refresh tokens. Persist each replacement refresh token in secure storage. Local sign-out clears the app’s session; users revoke access from ONE → Connected apps.

Verify your integration step by step

1. Start signed out. Open the app’s login control. Confirm ONE shows the intended application name and requested fields.
2. Test cancellation. Cancel the request. Your app should display a signed-out or cancelled state and should not enable data operations.
3. Exercise missing data. Request a profile field that your test profile has not filled. Select it, complete it in ONE, then review and allow access. An unselected optional field should not block authorization.
4. Complete a successful callback. Verify the SDK receives the full callback URL exactly once and the app switches to its signed-in screen.
5. Round-trip a value. Save theme = "dark", read it back, then delete it and confirm the missing-key result. Check that another app or user has a separate namespace.
6. Test session lifetime. Relaunch or reload with the supported secure storage configured. If Stay signed in was granted, confirm your storage saves replacement refresh tokens.
7. Revoke access. Disconnect the app or revoke the relevant field from ONE’s Connected apps. The next protected request should fail clearly; your app should not quietly display stale privileged data.

Use your registered identifiers in a real target build. The release verification notes distinguish compiled SDK checks from platform/device behavior still requiring your validation.

Installation and libraries

The full bundle is not required for every integration. Android and JVM projects resolve dependencies with Gradle/Maven. Websites can import the hosted module. Python and Ruby use a single file; other source-based platforms can use the relevant files or folder listed in their guide.

Maven repository · Integration notes

repositories { maven { url = uri("https://client.extremextechnology.com/repo") } }
// Android: Auth + Data + layout/dialog + encrypted persistence
implementation("com.extremex.one:exone-android:3.2.0")
// Other JVM applications: Auth + Data
implementation("com.extremex.one:exone-data:3.2.0")

Optional source bundle · all platforms in one archive

The Java, Android, browser, Python, Ruby, Go and Rust libraries share the same flow. The KMP and Apple sources are included for platform builds; review the verification notes in the download before shipping on devices.

API reference

Authorization: https://one.extremextechnology.com/oauth/authorize
API base: https://api.extremextechnology.com/one

Errors: 401 requires a valid session or fresh sign-in; 403 indicates missing or revoked access; 400 indicates invalid input; 413 means the request is too large; 415 requires JSON. Do not automatically retry a consumed authorization code or reuse a rotated refresh token.

Native sign-in follows OAuth for Native Apps: an external browser, S256 PKCE, callback validation and no embedded client secret.