> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frankieone.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OCR Journey

> Document capture and data extraction without biometrics, in one pre-assembled flow.

## What it does

The OCR journey walks an applicant through camera-based document capture, extracts the document
data, optionally lets the applicant review it, and settles with a single decision — with **no
biometric selfie** anywhere in the flow. FrankieOne assembles and maintains every screen and the
transitions between them — you mount a container and read the result.

That's the entire distinction from the [IDV journey](/docs/embedded-flows/journey/idv): choosing
between the two is a question of whether you need a selfie. If you do, use IDV; if you only need
document data, use OCR.

## What your applicant sees

<Steps>
  <Step title="Start (off by default)">
    An introductory screen before the flow begins. Enable with `withStart`.
  </Step>

  <Step title="Welcome (off by default)">
    An orientation screen. Enable with `withWelcome`.
  </Step>

  <Step title="Consent (off by default)">
    Captures consent for data processing. Enable with `withConsent`.
  </Step>

  <Step title="Capture">
    Vendor-driven camera capture of the identity document. No selfie step.
  </Step>

  <Step title="Extraction">
    The captured document is processed and its data extracted. A loading screen covers this gap —
    see `captureLoader` below.
  </Step>

  <Step title="Review (off by default)">
    The applicant confirms or corrects the extracted data. Enable with `withReview`.
  </Step>

  <Step title="Verifying (skipped when `triggerVerificationOnSubmit: false`)">
    Verification runs against the submitted data. A loading screen covers this gap — see
    `verifying` below. With `triggerVerificationOnSubmit: false`, this step and its loading screen
    are skipped entirely — nothing is submitted for verification, and the journey settles
    `success / captured` instead.
  </Step>

  <Step title="Result">
    The journey settles with a `JourneyResult`. See [Outcomes](#outcomes).
  </Step>
</Steps>

## Example

```javascript theme={null}
import OneSdk, { JourneyName } from '@frankieone/one-sdk';

const oneSdk = await OneSdk({ session: { token } });

const result = await oneSdk
  .journey(JourneyName.OCR, {
    container: document.getElementById('verify'),
    withConsent: true,
    withReview: true,
  })
  .start();
```

## Options that apply

| Option | Applies to ocr |
| - | - |
| `container`, `withStart`, `withWelcome`, `withConsent` | yes |
| `withReview` | yes — toggles the review screen between extraction and verification |
| `start`, `welcome`, `consent`, `review` | yes — each is the form module's own configuration for that screen, forwarded verbatim; `review` keeps its per-country and per-state structure — see [Form module: Configuration](/docs/sdk-reference/form-module/configuration) |
| `result` | yes — RESULT config per screen state, see [Result screens](/docs/embedded-flows/journey/configuration#result-screens) |
| `withResult` | yes — toggles the terminal result screen, on by default, see [Screens](/docs/embedded-flows/journey/configuration#screens) |
| `captureLoader` | yes — configures the loading screen shown during capture and extraction |
| `verifying` | yes — configures the loading screen shown while verification runs; skipped entirely when `triggerVerificationOnSubmit: false`, since no verification runs to cover |
| `triggerVerificationOnSubmit`, `maxAttempts`, `logo`, `style` | yes |
| `simulate`, `startAt` | yes — development only; `startAt` accepts both `'CAPTURE'` and `'REVIEW'` on ocr |
| `personal`, `document`, `retry` | no — eKYC only |

See [Configuration](/docs/embedded-flows/journey/configuration) for what each option controls, and the
[Journey reference](/docs/sdk-reference/journey#options) for the exhaustive type and default for every
option.

The `review` option itself is not a journey concept — it's the **form module's own configuration**,
forwarded verbatim, keeping the form module's per-country and per-state field structure exactly as
documented there. For the field shapes and how that structure is built, see
[Form module: Configuration](/docs/sdk-reference/form-module/configuration).

## Requirements and caveats

* The applicant needs a working camera to complete document capture — there is no selfie step to
  additionally provision for.
* Capture is vendor-driven. The journey abstracts over which vendor runs it, so nothing about a
  specific vendor's SDK is documented here. Which document types an applicant can capture depends on
  the configured vendor's capabilities — see [OCR module](/docs/sdk-reference/ocr-module) and
  [Vendor Customizations](/docs/sdk-reference/vendor-customizations).
* Vendor selection happens outside `journey()` entirely, in the recipe passed to `OneSdk({ recipe })`
  at initialization — `JourneyOptions` has no vendor key. `journey('ocr')` needs
  `recipe.ocr.provider.name` set in the recipe. Every journey, ocr included, also needs
  `recipe.form` configured, or the form module throws `Form recipe configuration is missing`. See
  [SDK Initialization](/docs/sdk-reference/sdk-initialization) for the recipe shape and
  [Vendor Customizations](/docs/sdk-reference/vendor-customizations) for per-vendor settings.
* If `withReview` is enabled and its address field needs autocomplete, set `googleApiKey` on the
  form module's provider configuration — see
  [Form module: Configuration](/docs/sdk-reference/form-module/configuration). Without it, address
  autocomplete will not work.

## Outcomes

An ocr journey settles with the same `JourneyResult` shape as every other flow — see
[Results](/docs/embedded-flows/journey/results) for the full outcome and reason-code contract. The
result itself carries the decision, not the extracted document data — see
[Reading extracted data](/docs/embedded-flows/journey/results#reading-extracted-data) for where that
data actually is once the journey settles.

One ocr-specific note: because capture depends on a vendor SDK, a vendor-side failure settles the
journey with `outcome: 'error'` and either `reason: 'vendor_load_failed'` (the vendor SDK failed to
load) or `reason: 'vendor_offline'` (the vendor was unreachable once loaded). Check `recoverable` and
`error.code` on both before deciding whether to offer a retry.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.