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 by cloning the source Inquiry into its own Persona environment, then maps the copied 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 creating the cloned 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 clones the source Inquiry — copying its data, government ID, and any documents — into a new Inquiry on Dakota’s side, and Dakota maps it into a new individual application. Because the whole verification is copied, the documents come across, not just the data fields. Documents are stored in Dakota’s own storage — they are not links back to Persona.

​
Transferred from the source

The clone copies the completed verification as the source collected it. From it, Dakota reads the following identity fields — Persona’s standard Connect field keys: Also transferred, from the Inquiry’s verifications and documents rather than its fields:

​
How many sides each ID type needs

An application is only document-complete when it holds a full identity document, and what counts as full depends on the ID type: A missing back side does not fail the import. The front is attached and the application stays document-incomplete until the back is supplied, so configure two-sided capture on the source verification if your customers use a driver’s license, ID card or residence permit.
Nationality often does not transfer, and it is required at submission. Persona returns nationality as an optional, nullable attribute on the government ID, and it is commonly absent for driver’s licenses. When it is absent, Dakota leaves nationality empty and the application cannot be submitted until it is set. Note also that Dakota reads nationality only from the government ID, never from an Inquiry field, so adding a nationality field to your source template does not carry it across. Send it on the application instead, as described in Completing an Imported Application.
Non-standard field names. Dakota reads the standard Persona field keys above. If your source verification stores the same identity data under different key names and something doesn’t pre-fill, tell us the keys you use — we’ll look at mapping them for your connection. Anything still missing can also be completed on the application afterward.

​
Proof of address

Proof of address transfers when the source verification collected it. Because the clone copies the source’s Document Verification (Address), Dakota downloads that document and attaches 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 what the source verification collected. The clone copies the completed verification as-is; anything the source never collected arrives blank. The identity fields Dakota reads 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.