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

# Persona Token Sharing

> Reuse a customer's existing Persona verification to onboard them to Dakota without re-collecting identity data or documents.

If your customer has already completed a verification with Persona, you don't have to make them go through it again. Dakota supports Persona's **Connect** flow: the Persona organization that originally verified the customer (the *source*) creates a single-use share token for that customer's completed Inquiry, hands it to you, and Dakota redeems it to create a customer and individual application pre-filled with the customer's identity data and government-ID documents.

This page covers how the flow works, what data transfers, and the one-time setup between your Persona organization and Dakota's. Once that's in place, [Importing Persona Tokens](/documentation/persona-token-import) covers creating and importing tokens.

<Info>
  **Persona references:** This flow is built on [Persona Connect](https://docs.withpersona.com/connect). Share tokens are created by the source organization as described in [Creating Share Tokens](https://docs.withpersona.com/creating-share-tokens).
</Info>

<Info>
  **Scope:** Token sharing is currently supported for **individual applicants only**. Business onboarding is not in scope for this flow.
</Info>

# How It Works

The Connect flow has three parties:

* **Source Organization** — the Persona customer that originally verified the end user. In Persona's words, "the Persona customer that shares an end user's data with its data sharing partner." They create the share token, scoped to a **Connection** with Dakota.
* **Dakota** — the **Destination Organization**, "the Persona customer that receives an end user's data from its data sharing partner." Dakota redeems the token inside its own Persona environment, then maps the data into a customer and application.
* **Persona** — handles the connection, the token, and the transfer of identity data and documents between the two organizations.

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant Source as Source Organization
    participant Persona
    participant Dakota

    Source->>Persona: Create share token<br/>(connection-id = Dakota, source-id = inq_...)
    Persona-->>Source: cnst_... token (default 14-day TTL)
    Source->>Dakota: Hand off token(s) (out-of-band)
    Dakota->>Persona: Redeem token into a Dakota Inquiry
    Persona-->>Dakota: Inquiry hydrated with the end user's data + government ID
    Dakota->>Dakota: Map data → individual application,<br/>download documents to storage
```

Unlike some other providers, **Persona redemption is asynchronous** — Dakota starts an import job that redeems each token in the background and completes when Persona finishes hydrating the Inquiry. That's why Dakota's import endpoint returns a **job** you poll, rather than results inline (see [Importing Persona Tokens](/documentation/persona-token-import#step-2-import-the-tokens-on-dakota)).

Share tokens are scoped to a single Connection and a single source record, and **only Dakota can redeem a token created for the Dakota connection** — Persona rejects any other organization.

# What Transfers and What Doesn't

When Dakota redeems a token, Persona hydrates a Dakota Inquiry with the end user's data, and Dakota maps it into a new individual application. Documents are copied into Dakota's own storage — they are not links back to Persona.

## Transferred from the source

Persona hydrates our Inquiry from yours by matching **field keys**. These are the keys we read — a source Inquiry that uses the same names transfers cleanly.

| Field key                                                    | Notes                                                               |
| ------------------------------------------------------------ | ------------------------------------------------------------------- |
| `name-first`, `name-middle`, `name-last`                     | Falls back to the name on the government ID if the fields are empty |
| `birthdate`                                                  | Required before an application can be submitted                     |
| `address-street-1`, `address-street-2`                       |                                                                     |
| `address-city`, `address-subdivision`, `address-postal-code` |                                                                     |
| `address-country-code`                                       | Two-letter country code                                             |
| `email-address`                                              | When present on the source Inquiry                                  |
| `social-security-number`                                     | US persons only; stored encrypted at rest                           |

Also transferred, from the Inquiry's verifications and documents rather than its fields:

| Data              | Notes                                                                                              |
| ----------------- | -------------------------------------------------------------------------------------------------- |
| **Government ID** | The actual **image files** (front + back), downloaded from Persona and attached to the application |
| Nationality       | Read from the government ID — for example a passport MRZ. Not taken from the residence address     |

<Info>
  **If you collect the same data under different key names**, we can still take it. Persona applies per-connection field mappings at redemption, which rename one of your fields onto one of ours — for example `name_first` onto `name-first`. Send us your key names and we'll configure it for your connection rather than asking you to change your template.

  A mapping can only point at a field in the list above. It renames; it cannot create a field on our side that doesn't exist — see [Not transferred](#not-transferred).
</Info>

## Proof of address

Proof of address **usually transfers**. If the source Inquiry ran a Document Verification (Address), we download that document and attach it to the application.

<Warning>
  **Persona will not share a document older than roughly three months.** Beyond that window it isn't included, and the customer supplies a current one on Dakota. This is a Persona limitation, not a Dakota one.
</Warning>

Recognised classifications are utility bills, bank statements, lease agreements, mortgage statements, insurance documents, tax letters and government correspondence. A document we can't confidently treat as residence proof is skipped rather than mislabelled.

## Not transferred

| Field                                                   | Why it doesn't transfer                                                                                                            | How to supply it                    |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
| Employment status, purpose of account, source of wealth | Not part of Persona's standard Inquiry data, so there's no field on our side for them to land in — whatever they're named on yours | Send them over our API              |
| Source-of-wealth documents                              | Not part of the identity transfer                                                                                                  | Upload over our API                 |
| Attestations (terms, privacy, info accuracy)            | Consent to **Dakota's** terms — your customer accepts these regardless of what they accepted with you                              | Collected at application submission |

**None of this requires sending the customer through our onboarding flow**, so the journey can stay in your app.

<Card title="Completing an Imported Application" icon="list-check" href="/documentation/completing-an-imported-application">
  How to supply every field above — getting an application token, sending the Dakota-specific fields, recording attestations, and submitting.
</Card>

<Info>
  **How much pre-fills depends on the source template.** Persona only hydrates fields it can match by key. A token always redeems, but any field your template doesn't collect — or names differently — arrives blank. The keys we read are listed under [Transferred from the source](#transferred-from-the-source); anything still missing is filled in when [completing the application](/documentation/completing-an-imported-application).
</Info>

# Prerequisites

Two things must be true on your side before any of this works. Both are between you and Persona — Dakota cannot arrange either one for you.

<Warning>
  **Connect must be enabled on your Persona account.** Connect is a separate product from standard Persona verification; having a Persona account does not automatically include it. If you don't see **Connect** in your Persona dashboard, contact Persona to have it enabled for your organization.
</Warning>

<Warning>
  **Your Persona API key needs permission to create share tokens.** Connect permissions are split between read and write. A key that can *read* connections and share tokens still cannot *create* them — you need the "create or update share tokens" permission on the specific key you use. Persona rejects a request from an under-scoped key with a `403` and a message about the API key lacking appropriate permissions, which reads like an account-level problem but is only the key's scope. If you hit that, check the key's permissions before anything else.
</Warning>

Persona also requires both organizations to sign a Connect agreement, executed separately — see the note at the end of the next section.

# Before You Start: Establish the Connection

Before any share token can be created, a **Connection** between your Persona organization (the source) and Dakota's Persona organization (the destination) must exist and be active. Per Persona: *"The Source Organization creates the Connection by indicating which Destination Organization they would like to share data with, and what types of data they would like to share. The Destination Organization activates the Connection, after which the Source and Destination Organizations are ready to share data."*

<Card title="Dakota's Persona Organization ID" icon="fingerprint">
  ```
  org_Hps67UWfvJgqk1Mqs6JiapyX
  ```

  Select Dakota as the **destination organization** with this ID when you create the connection. It is an identifier only — sharing it grants nothing, and no data can flow until Dakota activates the connection on its side.
</Card>

<Info>
  **Who does what.** You create the connection, Dakota activates it. You need Dakota's organization ID (above) to create it; Dakota does **not** need yours — the pending connection appears on Dakota's side already carrying your organization, and Dakota simply approves it.
</Info>

So the setup is a two-party handshake:

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant You as You (Source Organization)
    participant Persona
    participant Dakota as Dakota (Destination Organization)

    You->>Persona: Connect → Connections → create connection<br/>(destination = Dakota org_Hps..., data types to share)
    Persona-->>Dakota: Connection pending activation
    You->>Dakota: Ask Dakota to activate (confirm the environment)
    Dakota->>Persona: Activate the connection
    Persona-->>You: Connection active — you now have a connection-id (cxn_...)
```

What you need to do:

1. **Create the connection** in your Persona Dashboard under **Connect → Connections** (or via the Connect API), choosing Dakota (`org_Hps67UWfvJgqk1Mqs6JiapyX`) as the destination organization and the data types you want to share.
2. **Ask Dakota to activate it.** Dakota has to activate the connection on its side before it becomes usable — contact your Dakota representative to coordinate, and confirm which environment you're setting it up in (see the note below).
3. **Use the connection ID.** Once active, you'll have a **connection ID** (`cxn_...`) to pass when creating share tokens.

<Info>
  **Dakota must activate the connection.** You cannot complete the handshake alone, and Persona support cannot activate it for you. Contact your Dakota representative to coordinate.
</Info>

<Warning>
  **Match the environment.** Persona keeps environments separate. Create the connection in the same environment where your tokens will be created and redeemed, and make sure Dakota activates it in that same one. If Persona's connection screen asks for Dakota's *Environment* ID rather than the Organization ID above, request the matching one from your Dakota representative.
</Warning>

<Warning>
  **Both organizations sign a Persona agreement.** Persona notes that "both the Source Organization and the Destination Organization are required to sign the agreement with Persona (however, each agreement is executed separately)." Make sure your production Connect agreement with Persona is in place before you rely on this in production.
</Warning>

For the exact, current dashboard steps and API calls, follow Persona's own references:

* [Connect](https://docs.withpersona.com/connect) — overview, roles, and how connections are created and activated
* [Creating Share Tokens](https://docs.withpersona.com/creating-share-tokens) — the source-side token creation covered in Step 1 below

# Next

Once the connection is active, continue to **[Importing Persona Tokens](/documentation/persona-token-import)** — creating share tokens, importing them, and completing the application.