Skip to main content
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 covers creating and importing tokens.
Persona references: This flow is built on Persona Connect. Share tokens are created by the source organization as described in Creating Share Tokens.
Scope: Token sharing is currently supported for individual applicants only. Business onboarding is not in scope for this flow.

​
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.
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). 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. Also transferred, from the Inquiry’s verifications and documents rather than its fields:
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.

​
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.
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.
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

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

Completing an Imported Application

How to supply every field above — getting an application token, sending the Dakota-specific fields, recording attestations, and submitting.
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; anything still missing is filled in when completing the application.

​
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.
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.
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.
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.”

Dakota's Persona Organization ID

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.
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.
So the setup is a two-party handshake: 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.
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.
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.
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.
For the exact, current dashboard steps and API calls, follow Persona’s own references:
  • Connect — overview, roles, and how connections are created and activated
  • Creating Share Tokens — the source-side token creation covered in Step 1 below

​
Next

Once the connection is active, continue to Importing Persona Tokens — creating share tokens, importing them, and completing the application.