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 typically still needed

  • Employment status, purpose of account, source of wealth
  • Source-of-wealth documents
  • Attestations (terms of service, privacy policy, information accuracy)
  • SSN, if the applicant is a US person and it wasn’t carried across
  • Proof of address, if none transferred

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

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

Source-of-wealth documents, and proof of address if none transferred, go through the standard document upload endpoints.

​
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

Once every required field is populated, submit the application as you would any other.

​
What’s Next