Register for REL-ID SDK Events

The REL-ID SDK operates on an event-driven architecture, meaning that responses to API calls and updates are handled asynchronously via events rather than synchronous return values.

🧭 Purpose of Events

Events in the REL-ID SDK are triggered by the internal modules or plugins for several key reasons:

• 🔔 To notify the application asynchronously of updates or changes
• 🔁 To return responses to API calls made by the application
• 📊 To report internal process status
• 📥 To request input or additional data from the application in order to proceed with workflows

REL-ID IDV Workflow Diagram

RE-ID Workflow Diagram

flowchart TD
    %% Initialize SDK
    A[App invokes REL-ID SDK initialize] --> B[onInitialized]
    
    %% MTD Security Gateway
    B --> C{Is MTD enabled connection profile?}
    C -->|Yes| D[onUserConsentThreats OR onTerminateWithThreats]
    D --> E[takeActionOnThreats]
    
    %% Main Authentication Flow
    C -->|No| F[getUser]
    F --> G[setUser userId]
    G --> H{REL-ID SDK initialized?}
    
    %% Branch to Login or Device Activation
    H -->|Yes| I[Login WorkFlow]
    H -->|No| J[Additional Device Activation]
    
    %% Login Authentication Process
    I --> K[LDA Prompt OR getPassword]
    K --> L[Provide LDA OR setPassword password]
    
    %% Device Support Check
    L --> M{Does device support LDA?}
    M -->|Yes| N[LDA Authentication Process]
    M -->|No| O[Password Authentication Process]
    
    %% Additional Device Activation Decision
    J --> P{Device Access Status}
    P -->|if access to activated device| Q[REL-ID Verify Notification on activated Device]
    P -->|if no access to activated device| R[getActivationCode VerificationKey]
    
    %% Activated Device Path
    Q --> S[getActivationCode VerificationKey] 
    S --> T[setActivationCode activationCode]
    
    %% No Access Device Path
    R --> U[setActivationCode activationCode]
    
    %% Account Recovery Workflow
    V[Account Recovery or Lost Device Activation] --> W[getActivationCode verification Key]
    W --> X[setActivationCode activationCode]
    
    %% First-Time Activation
    Y[Activation Workflow] --> Z[getActivationCode verification Key]
    Z --> AA[setActivationCode activationCode]
    
    %% Biometric Verification Gate
    N --> BB{User accepts/rejects/fraud notification on activated device}
    O --> CC{RELID-IDV-SelfieBiometricTemplate challenge}
    
    %% User Response Handling
    BB -->|Accept| DD[Process User Acceptance]
    BB -->|Reject| EE[Handle User Rejection]
    BB -->|Fraud| FF[Execute Fraud Protocol]
    
    %% Biometric Challenge Responses
    CC -->|Accept| GG[Process Biometric Authentication]
    CC -->|Reject| HH[Alternative Verification Method]
    
    %% IDV Workflow Integration Points
    T --> II[REL-ID IDV WORKFLOW]
    U --> II
    X --> II 
    AA --> II
    
    %% Final Success Convergence
    DD --> JJ[onUserLoggedIn Response]
    EE --> JJ
    GG --> JJ
    HH --> JJ
    II --> JJ
    L --> JJ
    
    %% Workflow Completion
    JJ --> KK[User Successfully Authenticated]
    
    %% Security/Error Handling
    FF --> LL[Security Alert Generated]
    LL --> MM[Session Terminated for Security]
    E --> MM
    
    %% Styling
    classDef startPoint fill:#4caf50,stroke:#2e7d32,stroke-width:3px,color:#fff
    classDef endPoint fill:#2196f3,stroke:#1565c0,stroke-width:3px,color:#fff
    classDef decision fill:#ff9800,stroke:#ef6c00,stroke-width:2px
    classDef process fill:#9c27b0,stroke:#6a1b9a,stroke-width:2px,color:#fff
    classDef apiCall fill:#4caf50,stroke:#388e3c,stroke-width:2px
    classDef userAction fill:#ffc107,stroke:#f57c00,stroke-width:2px
    classDef security fill:#f44336,stroke:#c62828,stroke-width:2px,color:#fff
    classDef idvWorkflow fill:#00bcd4,stroke:#0097a7,stroke-width:3px,color:#fff
    
    %% Apply Classifications
    class A startPoint
    class KK endPoint
    class MM security
    class C,H,M,P,BB,CC decision
    class I,J,V,Y process
    class B,F,K,N,O,Q,S,R,W,Z,DD,EE,GG,HH,JJ apiCall
    class G,L,T,U,X,AA userAction
    class D,E,FF,LL security
    class II idvWorkflow

✅ Prerequisites for Receiving SDK Events

To correctly receive and handle SDK events, your application must follow these steps:

🧩 Step 1: Initialize the SDK

Use the initialize() API to start the SDK and establish a session.

⚠️

Important: You must set up your event listeners before initialization to capture key events like:

• onInitializeProgress
• onInitializeError
• onInitialized

🪝 Step 2: Register Event Listeners

Ensure all required event listeners are registered before calling any SDK workflows.

🔧

Each platform requires slightly different mechanisms to hook into events (e.g., event emitters, delegates, listeners).

🛠 Step 3: Setup for Advanced Workflows (e.g., IDV)

For advanced workflows such as Identity Verification (IDV):

• You must set callback instances (e.g., RDNAIDVCallbacks) after successful initialization.
• This is typically done inside the onInitialized callback.

💡

Following these steps ensures you never miss critical events and that your SDK

integration runs smoothly across all supported workflows.

Registering the event listener

Follow the steps in the below recipe guide to register a event listener

ℹ️

Note: The name of the callback event and the data it receives will vary depending on the scenario and the SDK function you are using.

For example:

• onUserEnrollmentResponse returns user ID, status, and error info.
• getIDVSelfieConfirmation returns match result and confidence score.
• onInitializeError returns error details about SDK startup.

Always refer to the specific API or workflow documentation to understand which event will be triggered and what its payload contains.