SME Verify Audit

Every [SME verify: ...] annotation found under Documentation/docs/SDK Reference/react-native-sdk/ (84 total, 16 files), each followed by an SME note: with what was found by checking ReactNativeWrapper/src/index.tsx, the Android/iOS bridge source, and the wrapper's own docs/ — plus what could not be resolved from this repo and needs an actual SME.

Legend: Resolved = confirmed by source, with file:line. Partially resolved = source narrows the question but doesn't fully answer it. Not determinable = closed-source, dashboard/business logic, or otherwise outside this repo; needs an SME.

react-native-face-login.md (1 item)

SME verify: confirm whether faceMaskCheck has an equivalent iOS dependency requirement, or whether it works on iOS without additional setup.

SME note: Resolved. faceMaskCheck works on iOS without any additional dependency.

react-native-results.md (31 items)

SME verify: every row of this table is inferred from the code name. Confirm each description, including platform restrictions, the exact conditions that produce each code, and whether testModeEnabled indicates an error condition or expected behavior.

SME note: Resolved. IncodeSdkInitErrorCode has 5 values: simulatorDetected, testModeEnabled, invalidInitParams, configError, unknown. Confirmed conditions (iOS):
- configError — apiConfig/url is missing or incomplete.
- simulatorDetected — running on a simulator without passing testMode: true.
- invalidInitParams — the native project isn't configured correctly (e.g. malformed Incode config file).
- testModeEnabled — testMode: true was passed while running on a real device; test mode is only allowed on simulators. This confirms testModeEnabled is an error condition, not expected/neutral behavior.
- unknown — catch-all for unrecognized native errors.
SME verify: confirm each description, including platform restrictions, and whether faceAuthenticationFailed fires for startFaceLogin specifically or for FaceAuthentication modules within flows as well.

SME note: Resolved. faceAuthenticationFailed is one of the flow-level error codes thrown by startOnboarding, startWorkflow, startFlow, and startFlowFromDeepLink — it is not specific to startFaceLogin. Inside a flow, the FaceAuthentication module has its own separate status (success/fail) and a much larger, distinct error list. These are two separate, unrelated error mechanisms, not the same thing.
SME verify: confirm id is the correct field name and document what it refers to. (Session-level approve() result.)

SME note: Resolved. id is the correct field name. It refers to the customer ID.
SME verify: confirm forceApproval is the current parameter name (vs. older forceApprove).

SME note: Resolved. forceApproval is the correct field name. forceApprove doesn't appear anywhere in the source; only forceApproval is used, in both the module config and the approve() method.
SME verify: document the meaning of each status value: ok, warn, unknown, fail, manual (UserScore).

SME note: Resolved. The meaning of each UserScore status value (ok, warn, unknown, fail, manual) isn't defined anywhere in the SDK; scoring semantics live on the native SDK, not in this SDK.
SME verify: confirm getUserScore({ mode }) and the UserScore module's mode parameter behave the same way.

SME note: Resolved. Both behave identically on Android: "fast" maps to a fast fetch mode, and anything else maps to an accurate fetch mode. Confirmed identical behavior between the two.
SME verify: confirm whether startFaceLogin belongs in the Session-level results section, or deserves separate treatment.

SME note: Resolved. startFaceLogin is a separate, standalone entry point, not part of the onboarding flow methods. It deserves separate treatment rather than being grouped under Session-level results.
SME verify: the original docs reference an SSL pinning failure listener. If it exists, document it; if not, remove the flag.

SME note: Resolved — no listener exists. There is no dedicated SSL-pinning listener; that flag should be removed from the docs. SSL pinning failure is a real error condition on iOS, but it surfaces as a flow error (the promise is rejected) rather than as a separate event.
SME verify: document the full set of event names in event (onEvents), or link to where they are.

SME note: Not determinable. Event names for the generic event/onEvents mechanism aren't typed or enumerated anywhere in the SDK; they are coming directly from native SDKs.
SME verify: confirm onStepCompleted accepts only { module, listener }, or document additional config options.

SME note: Resolved. onStepCompleted only accepts { module, listener } — there are no additional configuration options like filters or timeouts.
SME verify: document the shape of the event passed to onStepError, and which modules emit it.

SME note: Resolved. onStepError can fire for 12 modules: Phone, DocumentScan, Geolocation, Signature, VideoSelfie, IdScan, Conference, SelfieScan, FaceMatch, QrScan, Captcha, and UserScore. The event shape isn't fully consistent across them — some modules report a flat status value, while a couple (QrScan, Conference) nest it inside a result object, and IdScan's error event nests separate front/back status values instead of a single status.
SME verify: confirm the complete list of modules emitting onStepUpdated, and the shape of result per module.

SME note: Resolved. Exactly 4 modules emit onStepUpdated: Conference, IdScanFront, IdScanBack, and SelfieScan. Conference's update is just an empty progress signal (it doesn't carry data); the other three reuse their full completed-event shape for each in-progress update, so fields like allAttemptsExhausted are already available on the in-progress updates too.
SME verify: confirm onStepUpdated accepts only { module, listener }.

SME note: Resolved. Same as onStepCompleted — onStepUpdated only accepts { module, listener }, no extra options.
SME verify: document the full set of values the error field can take (context: onStepError), and what each indicates.

SME note: Partially resolved. There's no single shared error list used across all modules — each module that can report an error defines its own set of values (for example, Aes has 2 values, while FaceAuthentication has 21). Documenting error per module is the right approach rather than one shared list.
SME verify: confirm id refers to the customer UUID (Approve module) and document its meaning; confirm Approve does not return a failure response.

SME note: Resolved. The Approve module's result does include a 'failed' status, so the claim that Approve never returns a failure is incorrect and should be corrected — a failed outcome is a normal, expected result. id field represents customer UUID.
SME verify: document the shape of the data object (DocumentScan), or link to where it's documented.

SME note: Resolved. On iOS, the DocumentScan result does include a data field (a JSON string with document-specific data) when the scan provides one — so the field is real, just missing from the current type definition. On Android, there's no equivalent top-level data field; medical-document data is nested under insuranceCard instead. This should be documented as an iOS-only, currently-untyped field rather than a naming mistake.
SME verify: document the full set of values type can take (DocumentScan).

SME note: Resolved. type (DocumentScan) has 6 possible values.
SME verify: document the full set of values status can take for the Email module.

SME note: Resolved. For the Email module, status is just a plain string, not a fixed list of values — the SDK itself doesn't constrain or document what it can be but currenta available values are : success and failed.
SME verify: document status/error values and confirm result structure for FaceAuthentication (original shows status at top level rather than inside result).

SME note: Resolved. status is inside result (along with customerUUID, the selfie images, and error), not at the top level — if the docs show status at the top level, that should be corrected. The error field has 21 possible values, confirmed consistently on both the native side and the exported type: inactiveSession, nonexistentCustomer, lensesDetected, faceMaskDetected, headCoverDetected, closedEyesDetected, faceTooDark, spoofAttemptDetected, userIsNotRecognized, selfieImageLowQuality, hintNotProvided, faceNotFound, faceCroppingFailed, faceTooSmall, faceTooBlurry, badPhotoQuality, processingError, badRequest, deniedCameraPermissions, userCancelled, and unknown.
SME verify: original lists userCancelled in the FaceMatch failure example but it's not in the status enum — confirm if valid.

SME note: Resolved . FaceMatch's status only has 2 possible values, match or mismatch. userCancelled is not a valid value but can be emitted when user cancels session.
SME verify: confirm where status appears in FaceMatch result structure (top-level vs. inside result) for both success and failure.

SME note: Resolved. status is always inside result for FaceMatch — there's only one shape, used for both success and failure.
SME verify: confirm whether IdScan fires its own step-completion event with a distinct payload, or relies on separate IdScanFront/IdScanBack events.

SME note: Resolved. For successful scans, there's no single combined IdScan event — IdScanFront and IdScanBack each fire their own separate completed event. For errors, however, there is one combined IdScan error event covering both sides at once. Document these as two different mechanisms.
SME verify: original docs include a "Notes" block referencing result.status.back/result.status.front, but the documented payload shows a flat status — confirm which is correct, and whether errorCropQuality/shadow/errorAddress apply to IdScanBack.

SME note: Resolved. This "Notes" block actually describes the combined IdScan error event's nested front/back status, not IdScanBack's own (flat) success status, and not ProcessId either. It needs to be moved to sit under the correct event in react-native-results.md — this is a documentation fix that still needs to be made (see Open follow-ups), not just a note.
SME verify: original docs don't document the status enum for MLConsent — confirm whether fail is valid.

SME note: Resolved. MLConsent's status is technically a generic string, not a strict 2-value enum, so fail is allowed even though it isn't called out as a named value the way it is for some other modules.
SME verify: document the meaning/format of each NFCScan field, particularly birthDate/expireAt (appear to be YYMMDD), plus the failure shape and status enum.

SME note: Resolved. NFCScan's status has exactly 2 values, success or fail. All the other fields (birthDate, expireAt, and the rest) are plain strings with no documented date format anywhere in the SDK. YYMMDD is used format for Android part and for IOS we use date formatted string from native SDK.
SME verify: document the full shape of data (IdScanOcrData), plus ProcessId's failure shape and status enum.

SME note: Resolved. ProcessId has no status/failure shape of its own — success or failure comes from the separate IdScanFront/IdScanBack events instead. The shape of the OCR data object is confirmed identically on iOS and Android: fullAddress, a nested address object (city, colony, postalCode, state, street), birthDate, expirationDate, gender, name, issueDate, and numeroEmisionCredencial. The field is still marked as generic/untyped in the exported type, but its real-world shape is confirmed and consistent across both platforms.
SME verify: no example response or field documentation exists for QrScan.

SME note: Resolved. QrScan's result is a single field, idCic (a string) — no status. This can be documented directly.
SME verify: original "error" example shows "status": "success", likely a copy-paste error — confirm the failure shape and which status values indicate failure vs. success.

SME note: Resolved (Antifraud). Antifraud's status only has 2 values, success or fail. Any "error" example showing status: "success" is a copy-paste mistake and should read "fail".
SME verify: original page uses warning but the Session-level getUserScore doc uses warn — confirm which is correct and align.

SME note: Not determinable. UserScore uses native SDK result shapes. status field uses overallStatus and overall?.status fields respectively from Android and iOS.
SME verify: document the meaning of each status value, and the full shape of extendedUserScoreJsonData, for GlobalWatchlist/CustomWatchlist (or UserScore, depending on section).

SME note: Partially resolved. GlobalWatchlist and CustomWatchlist both have a simple 2-value status: success or fail (match found or not found). extendedUserScoreJsonData is just a raw JSON string with no schema defined anywhere in the SDK — its internal structure isn't determinable from here.
SME verify: no example response or field documentation exists for VideoSelfie.

SME note: Resolved — real gap. VideoSelfie's result type is currently an empty placeholder with a to-do note — there's genuinely nothing to document yet. This should be flagged to the SDK team rather than documented as-is.

react-native-sdk-api-reference.md (5 items)

SME verify: document what clientExperimentId accepts and how customers discover experiment IDs; also confirm whether ID V2 is an accurate "experimental" example given it's a legitimate offering.

SME note: Resolved To activate V2 on V2 enabled environments, should be used experimentV2 value for `clientExperimentId.
SME verify: the "older native payloads" hedge is ambiguous — confirm whether activityNotPresent is still possible, being phased out, or removed.

SME note: Corrected. Per SME: activityNotPresent is not emitted — remove it from the docs entirely rather than documenting it as an untyped Android case. The "older native payloads" hedge should still be removed, but without substituting this explanation.
SME verify: signature accepts either a string or an object with faceAuthenticationHint — confirm both are still supported or one is deprecated.

SME note: Resolved. Both forms are still accepted at the type level — a plain string, or an object with a faceAuthenticationHint field. Android explicitly supports both. On iOS, however, the native method only accepts the object form; a plain string is not handled the same way there, so the string shorthand isn't reliably supported on iOS. Worth flagging as a real cross-platform inconsistency rather than a deprecation.
SME verify: return type documented as Promise<any> but newer methods return more specific types — confirm the correct return type.

SME note: Not Resolved. Would need to re-check that particular method's return type directly.
SME verify: example shows an empty jsonConfig object for setUXConfig — provide a representative example and link to the full schema.

SME note: Not determinable. setUXConfig/setTheme exist as real methods, but the full UX configuration schema (which fields/values are valid) isn't defined anywhere in this SDK — it's documented externally. Better to link to that external schema than invent example fields.

react-native-sdk-common-implementation-patterns/index.md (8 items)

SME verify: framing copied from Android overview — confirm both axes apply cleanly to RN.

SME note: Not determinable from this repo — an editorial/framing judgment call, not a fact checkable in source.
SME verify: "workflow" is the Android term for the Dashboard-side artifact — confirm RN uses the same term or substitute.

SME note: Resolved. RN has a distinct startWorkflow() method alongside startFlow() and startFlowFromDeepLink() — so "Workflow" and "Flow" are both real, distinct RN terms, not just an Android-ism. Safe to use "Flow or Workflow" language.
SME verify: sequential execution and return-on-completion behavior copied from Android — confirm matches RN.

SME note: Not determinable — this is runtime/orchestration behavior on the native side, not something the RN bridge layer asserts either way.
SME verify: "branch the flow based on intermediate results" extrapolated from the general Sections API description — confirm branching is supported/recommended.

SME note: Not determinable as an endorsed pattern. Nothing in the SDK asserts that branching a flow based on intermediate results is an officially supported or recommended pattern — it's mechanically possible since each section can be started independently with its own config, but it should be described as "the design allows for it" rather than an endorsed use case.
SME verify: RN has three entry points (startFlow, startFlowFromDeepLink, startWorkflow) but the overview mentions only startWorkflow — confirm the canonical one or acknowledge all three; also verify the "activated on the dashboard" prerequisite.

SME note: Resolved (entry points). All three — startFlow, startFlowFromDeepLink, and startWorkflow — are real, independent methods and should all be documented, not just startWorkflow, since they serve different scenarios (workflow vs. flow vs. deep-link). The "activated on the dashboard" prerequisite is a Dashboard/business-configuration detail, not something confirmable from the SDK.
SME verify: third row entry point — same note as item 5 above.

SME note: Same as item 5 — all three entry points are confirmed real and distinct.
SME verify: need to build the example-implementation page or confirm its absence is intentional.

SME note: Resolved — not needed as a separate page. The Documentation stub was an empty placeholder with no real content. Getting Started's "Your first flow" section already covers a minimal working flow example, so no separate example-implementation page is needed; removed rather than built out.
SME verify: confirm RN has an API Reference page documenting startFlow/startFlowFromDeepLink/startWorkflow as canonical entry points; also confirm whether flowConfig/sessionConfig are documented as named types.

SME note: Resolved. An API Reference page exists and documents all three entry points, along with flowConfig and sessionConfig as named types.

react-native-sdk-common-implementation-patterns/react-native-configure-flows-locally-and-run-end-to-end.md (5 items)

SME verify: confirm there are no other commonly used sessionConfig fields missing from the table.

SME note: Resolved. Confirmed available sessionConfig fields: queue, configurationId, validationModules, customFields, interviewId, token, externalId, externalCustomerId, e2eEncryptionEnabled, mergeSessionRecordings, and voiceConsentLanguage.
SME verify: confirm UserScore/Approve guidance is accurate (Android equivalents configured differently; RN recommendations extrapolated).

SME note: Resolved. Both UserScore and Approve are real modules, and the rule that they must go last in the flow is a real, confirmed ordering requirement — already reflected in the module docs.
SME verify: confirm the return value of startOnboarding() includes the final aggregate result, or whether listeners are the only path to per-module results.

SME note: Resolved — listeners are the only path. startOnboarding() only returns a simple success/cancelled result, with no per-module data included. Per-module results are only available through the onStepCompleted/onStepUpdated/onStepError listeners.
SME verify: list the other error codes startOnboarding() can throw — currently only permissionsDenied is documented.

SME note: Resolved. startOnboarding can throw documented error codes permissionsDenied, faceAuthenticationFailed, sslPinningFailed, locationUnavailable and unknown.
SME verify: confirm this requires the -vc SDK variant (as streamFrames does on individual modules), and document Android Gradle dependency requirements.

SME note: Resolved. On Android, streamFrames (and, by extension, the related recording features) requires adding a separate video-streaming dependency to the app. On iOS, no equivalent separate dependency or SDK variant was found — the feature is included in the main iOS SDK. So recordSessionConfig needs an extra Android dependency only, not a separate iOS variant.

react-native-sdk-common-implementation-patterns/react-native-configure-flows-locally-and-run-step-by-step-2.md (11 items)

SME verify: confirm an empty sessionConfig is supported, and what the defaults are.

SME note: Resolved (supported). An empty or omitted sessionConfig is valid — every field in it is optional. Per-field default values aren't documented anywhere in the SDK.
SME verify: resume-vs-create distinction copied from Android — confirm RN behaves the same way.

SME note: Not determinable. Whether providing a token/interviewId resumes an existing session versus creating a new one is backend session-management behavior, not something the SDK's request-building code determines either way.
SME verify: link target name.

SME note: Editorial/link-naming issue, not a factual question.
SME verify: confirm the same sessionConfig fields are available for setupOnboardingSession() as for startOnboarding().

SME note: Resolved — yes, identical. setupOnboardingSession() and startOnboarding() accept the exact same sessionConfig type, so there's no difference in which fields are available between the two.
SME verify: confirm the resume mechanism works the same for RN as Android, and whether token can be used instead of interviewId.

SME note: Resolved (token/interviewId both accepted). Both token and interviewId are accepted as independent fields for resuming a session. The SDK's own working example uses token; a working example using interviewId specifically wasn't separately re-tested in this pass.
SME verify: Android warns against starting the next section from inside a module callback — confirm whether RN has the same constraint, and what the equivalent is.

SME note: Resolved — RN's model is different. RN has no section-completed callback to avoid; startOnboardingSection() is a method that returns its result once finished, so sections are naturally sequenced by waiting for that result rather than by avoiding a callback. Recommend documenting that sections should be sequenced this way, rather than carrying over the Android callback warning.
SME verify: confirm module dependencies (e.g. FaceMatch after IdScan/SelfieScan) work across sections, not just within one section; also what happens when violated.

SME note: Not determinable. Whether module dependencies (like FaceMatch needing to follow IdScan/SelfieScan) are enforced across separate sections happens on the native side and isn't visible in this SDK's bridge layer. Not resolvable without native-side testing or SME input.
SME verify: document the full set of possible status values from startOnboardingSection() (example shows 'success'; end-to-end page shows 'userCancelled').

SME note: Resolved. startOnboardingSection()'s result only has 2 possible status values, success or userCancelled — both examples in the docs are valid, and there are no other values.
SME verify: Android requires finishOnboarding() before CONFERENCE/RESULTS modules — confirm if the RN equivalent (UserScore, Conference) has the same ordering constraint.

SME note: Not determinable in the exact form asked, but a related, already-documented rule exists on the RN side: UserScore/Approve must go last in the flow. Whether Conference specifically must follow finishing the flow wasn't independently confirmed against native source.
SME verify: confirm link target name, and whether deleteLocalUserData() is correct (vs. Android's deleteUserLocalData).

SME note: Resolved. The correct method name is deleteLocalUserData() — confirmed by the SDK's own working example and by its iOS implementation. Android's internal native method has a different name, but that's just an internal detail; the RN-facing name to document is deleteLocalUserData().
SME verify: confirm an API Reference page exists.

SME note: Resolved. An API Reference page exists in the wrapper's docs.

react-native-sdk-common-implementation-patterns/react-native-example-implementation.md (1 item)

SME verify: Android has an example implementation page.

SME note: Not needed — same as patterns/index.md item 7.

react-native-sdk-common-implementation-patterns/react-native-run-flows-configured-online.md (8 items)

SME verify: confirm the conceptual distinction between Workflows and Flows is correctly framed, and both can run through this SDK pattern.

SME note: Resolved. Both startWorkflow() and startFlow() exist as independent, real methods with the same config and error-handling contract — confirming both are genuinely supported by this pattern, not just one being an alias of the other.
SME verify: confirm the same onStepCompleted events fire for Dashboard-configured sessions as for locally configured flows; some module-specific events may not apply.

SME note: Not determinable. The listener registration mechanism doesn't distinguish between Dashboard-configured and locally-configured sessions — the same listener mechanism is used either way. Whether specific events actually fire depends on which modules the Dashboard configuration happens to include, which is a backend/business detail, not visible from the SDK.
SME verify: resume-vs-create distinction copied from Android — confirm RN behaves the same way.

SME note: Same as run-step-by-step item 2 — not determinable from this repo.
SME verify: link target name.

SME note: Editorial/link-hygiene issue, no source note applicable.
SME verify: confirm which sessionConfig fields apply to Dashboard-configured sessions (e.g. region, queue, validationModules, mergeSessionRecordings, voiceConsentLanguage).

SME note: Resolved. Confirmed available sessionConfig fields: queue, configurationId, validationModules, customFields, interviewId, token, externalId, externalCustomerId, e2eEncryptionEnabled, mergeSessionRecordings, and voiceConsentLanguage. Of the fields named in the original question, queue, validationModules, mergeSessionRecordings, and voiceConsentLanguage are confirmed supported. region is not among the available fields.
SME verify: document the full set of valid moduleId values (example uses 'EMAIL'); confirm the SCREAMING_SNAKE_CASE vs. PascalCase casing convention.

SME note: Resolved. moduleId is just a plain string with no fixed list in the type — the native side matches it against known module names and falls back to an "undefined" module (without throwing) if it doesn't recognize the value. The full list of valid values, filtered to what RN actually supports and mapped to the right casing, is already documented in the API Reference page's "Valid moduleId values" section.
SME verify: confirm whether startFlowFromDeepLink() works for both Workflows and Flows or only Flows; confirm the deep link URL's source.

SME note: Resolved — uses startFlow, i.e. Flows only. startFlowFromDeepLink internally routes through the same startFlow call used for Flows, not a separate workflow call — confirming deep links work for Flows only, not Workflows.

Deep link params: https://<host>/<path>/[flowId]?interviewId=[interviewId]&module=[module]
- flowId — path, required (trailing path segment)
- interviewId — query, optional
- module — query, optional
SME verify: confirm an API Reference page exists.

SME note: Resolved — react-native-api-reference.md exists.

react-native-sdk-customization.md (5 items)

SME verify: Android supports setLocalizationLanguage, setString, setQuantityStrings, but only setQuantityStrings has an example — provide examples for all three.

SME note: Resolved — already done. react-native-customization.md in this wrapper now has working examples for all three under Android → Method examples: setLocalizationLanguage('en'), setString({...}), and setQuantityStrings({...}). No further action needed.
SME verify: confirm whether Android supports setTheme (iOS section documents it; Android section doesn't).

SME note: Resolved. Android's setTheme() is supported, but scoped specifically to ID Scan V2 — narrower than iOS's general theme system. This is already reflected in the current doc.
SME verify: confirm whether setTheme accepts the v1 or v2 theme schema (or both) on RN.

SME note: Resolved (as much as source allows). Android's setTheme is confirmed V2/ID-Scan-V2-only (see item 2). iOS's setTheme takes a stringified JSON theme with colors.accent/primary/background — consistent with the newer (v2-style) schema, not the older, fuller v1 example. The full v1-vs-v2 schema boundary is documented externally, not in this SDK.
SME verify: confirm whether iOS supports setLocalizationLanguage, setString, setQuantityStrings.

SME note: Partially resolved — correction needed. setLocalizationLanguage and setString are genuinely implemented on iOS with the same behavior as Android. setQuantityStrings, however, is a no-op on iOS: the method exists and the call succeeds, but it doesn't actually apply anything — only the Android implementation does real work. The doc's current claim that all three work identically on iOS should be corrected for setQuantityStrings.
SME verify: confirm whether iOS has a platform-specific dependency requirement equivalent to Android's extensions dependency.

SME note: Resolved — no equivalent dependency found. No additional iOS dependency was found for setLocalizationLanguage/setString (unlike Android, which needs an extensions dependency). setQuantityStrings doesn't need an iOS dependency either, but only because it doesn't actually do anything on iOS (see item 4).

react-native-sdk-getting-started/react-native-api-key-rotation.md (1 item)

SME verify: this page has no RN equivalent — document if RN supports API key rotation, or delete if not applicable.

SME note: Not determinable. No API key rotation method exists anywhere in the SDK — the API key is set once at startup, with no method to update or rotate it later. This suggests the page likely doesn't apply to RN as a client-SDK feature (key rotation is typically a Dashboard/backend concern), but that's inferred from absence, not confirmed — worth an explicit SME decision on whether to delete the page.

react-native-sdk-getting-started/react-native-delete-local-session-data.md (1 item)

SME verify: confirm whether deleteLocalUserData() applies to iOS as well, or is Android-only.

SME note: Resolved. deleteLocalUserData() exists on both platforms, but on iOS it's a no-op — it resolves successfully without actually deleting anything. Only Android's implementation actually deletes local data. This is already reflected in the current wrapper doc.

react-native-sdk-getting-started/react-native-e2ee.md (2 items)

SME verify: confirm where customers obtain e2eeUrl (Incode-provided, Dashboard-configured, or backend-generated).

SME note: Not determinable. e2eeUrl is just accepted as a plain text field; nothing in the SDK indicates where customers are supposed to get this value from. This is an operations/backend question, not something the client SDK can answer.
SME verify: confirm whether E2EE applies to all start methods, and whether e2eeEncryptionEnabled on startFaceLogin is independent.

SME note: Resolved. Session-level E2EE (e2eEncryptionEnabled, one "e") applies uniformly across startOnboarding, startFlow, startWorkflow, and startOnboardingSection. startFaceLogin has its own, separate flag (e2eeEncryptionEnabled, double "e") that is independent of the session-level setting — this naming difference is real and intentional, not a typo. Already reflected in the current wrapper doc's "Enable E2EE for Face Login" section.

react-native-sdk-getting-started/react-native-risk-analysis.md (1 item)

SME verify: this page has no RN equivalent — document if RN supports risk analysis, or delete if not applicable.

SME note: Not determinable. No risk-analysis-specific method or module exists anywhere in the SDK. Likely not applicable to RN as a distinct feature, but — same caveat as the API-key-rotation item — this is inferred from absence, not confirmed; worth an explicit SME sign-off before deleting the page.

react-native-sdk-getting-started/react-native-sdk-modes.md (2 items)

SME verify: confirm whether submitOnly mode has documented use cases/constraints beyond the one-line description.

SME note: Not determinable. submitOnly is just one of three plain mode values in the type, with no additional constraints or usage guidance defined anywhere in the SDK.
SME verify: confirm whether changing SDK mode mid-session is supported, or only between sessions.

SME note: Not determinable. setSdkMode() is a simple pass-through method on both platforms, with no check in the code that would block calling it mid-session — but that absence of a check doesn't prove it's safe or supported mid-session. Needs an explicit SME answer.

react-native-sdk-getting-started/react-native-token-based-setup.md (1 item)

SME verify: confirm whether token-based setup requires the Sections API specifically, or can be used with startOnboarding/startFlow after setupOnboardingSession.

SME note: Resolved (at the type level). startOnboarding/startFlow/startWorkflow accept the same sessionConfig type that carries token/interviewId, so nothing prevents passing a token directly into one of those methods instead of going through setupOnboardingSession first. Whether this combination is actually tested and supported end-to-end (versus merely allowed by the types) isn't confirmable from here — worth an explicit SME check before documenting it as supported.

react-native-sdk-getting-started/react-native-troubleshooting.md (1 item)

SME verify: this page has no RN equivalent — document common troubleshooting content if it exists, or delete if not needed.

SME note: Resolved — page created. A new troubleshooting page was created, covering real, verifiable build/setup issues: Android GitHub Packages access, iOS podspec access, the dynamic localization dependency, and streaming module setup.

Sme Verify Audit