Skip to main content
Importing a share token creates a customer and an application with the identity data already filled in. A few fields aren’t part of any identity verification, so they still need supplying before the application can be submitted. This applies equally to applications imported from Sumsub and Persona — the completion flow is the same for both.
Importing does not skip verification; it pre-fills it. Once submitted, the application goes through Dakota’s normal compliance review like any other.

​
What’s still needed

Required before the application can be submitted:
  • Employment status, purpose of account, source of wealth — these are values on the application, not documents
  • Attestations (terms of service, privacy policy, information accuracy)
  • Identity documents, if none came across with the token
Optional:
Source of wealth is a value, not a document. source_of_wealth is a required field on the application — the accepted values are listed below. Source-of-wealth documents are a separate, optional thing; you don’t need to collect one to submit.

​
Two ways to complete it

Send the customer the application link and they fill it in on Dakota, or send the data over the API and keep the customer inside your own app. The rest of this page covers the API route.

​
1. Get an application token

These endpoints authenticate with an application token, not your API key. Fetch the customer after the import and read it from application_url:
cURL
Take the token query parameter and send it as x-application-token on the calls below.
The token can be re-read any time with GET /customers/{customer_id} — there is no separate rotation endpoint. It remains valid for 90 days after creation, and may be stored and used server-side (backend-to-backend); a browser handoff is not required.

​
2. Send the Dakota-specific fields

cURL
X-Idempotency-Key is required. Without it the request is rejected before the body is read.
Values must be exactly one of: purpose_of_account and source_of_wealth accept multiple values.
Employment status is required before an application can be submitted, so it’s worth sending as part of your import routine rather than leaving it for later.
Validation notes. Email addresses on example or test domains are rejected. employment_status applies to individual-role applicants only; sending it for a UBO or control-person role is rejected.
For US persons, ssn can be sent on the same call when it wasn’t carried across from the source.

​
3. Upload any remaining documents

Identity documents are required if none came across with the token. Proof of address and source-of-wealth documents are optional — upload them if you have them, but neither blocks submission. All of them go through the standard document upload endpoints, which list every accepted document type.
Document field keys differ by owner. An individual direct document upload keys the field type; an application (business or EDD) document upload keys it document_type. Use the key that matches the endpoint you’re calling.

​
4. Attestations

Attestations are not carried across by a share token, and they can’t be. An attestation you already hold records consent to your terms; your customer still has to accept Dakota’s legal agreements before the application can be submitted.
You are responsible for presenting the documents. If you collect consent in your own interface rather than sending the customer to Dakota’s hosted form, you must show your end users each agreement and record their acceptance honestly. Each attestation stores the attestor’s name, IP address and the time they accepted.
See Submitting Attestations via API in the Customer Onboarding guide for worked examples of the calls. The section directly above it lists every agreement, with a link to each document your customer must be shown.
Submit e_sign first. Every other attestation is rejected until e-sign consent is recorded, and each must carry a timestamp later than it.
Types: e_sign, terms_of_service, privacy_policy, funds_transfer_agreement, lead_bank_privacy_policy, information_accuracy. See the Submit Attestation reference for the full request schema. If you would rather not present the agreements yourself, send the customer the application link and they will accept them on Dakota.

​
5. Submit

Before submitting, confirm the application is complete with GET /applications/{application_id}?include=validation and read the ready flag together with missing_fields / missing_documents, rather than relying on submission errors. Submit once ready is true.

​
What’s Next