Bring Your Own Identity Verification to E-Signatures

Can I use my own identity verification provider for e-signatures?

6 identity verification methods, from a government ID plus liveness check to single sign-on, can carry over into TurboSign embedded signing, so yes, you can keep your own provider. Your backend verifies the signer with the vendor you already use, then passes that result when it requests a signing URL. TurboSign checks the assertion and opens a single-use link that expires in 5 minutes, without asking the signer to verify a second time, and the vendor name and reference ID land in the document audit trail.

Key takeaways

• 6 verification methods can be recorded with an assertion: ID document, ID document plus liveness, knowledge-based questions, an authoritative database, single sign-on, or a described other method.
• 24 hours is the default maximum age of a verification, adjustable per signer from 5 minutes to 7 days.
• 5 minutes is the lifetime of the single-use signing URL TurboSign issues for an externally verified signer.
• 2 organization settings gate the feature, embedded signing enabled and Allow external identity verification, and TurboSign checks both again every time a URL is issued.
• 0 signing-link emails go out when you send with sendEmail set to false, so signing happens only in your app; TurboSign still emails the completed copy.

How does bring-your-own identity verification work?

1. 1

   An admin allows external identity verification

   In the E-Signature settings, an organization admin enables embedded signing, turns on Allow external identity verification, and lists the domains allowed to embed the signing page. Embedding is deny by default. Your integration can read these settings with getEmbeddedSigningSettings() before it sends anything.

2. 2

   You create the signer with your provider name

   Give the recipient an identityVerification block with mode external_idv, the provider name you will assert, and an optional maxAgeMinutes. Send with sendEmail: false so TurboSign sends no signing-link emails.

3. 3

   Your vendor verifies the signer, in your app

   Run the check the way you already do. TurboSign is not in this step and never calls your vendor.

4. 4

   Your backend asserts the result and gets a URL

   Call createSigningUrl with an identityAssertion: provider, verificationId, verifiedAt, and subjectEmail, plus optional method, assuranceLevel, verifiedName, and an https evidenceUrl. TurboSign validates it and returns a single-use URL.

5. 5

   The signer signs inside your product

   Open the URL in an iframe, a redirect, or a new tab within 5 minutes. The signer goes straight to the document with no passcode step.

What does the integration look like in code?

Two SDK calls in TypeScript. The same methods exist in the Python, Go, PHP, Java, and Ruby SDKs, and the raw REST endpoint is POST /turbosign/documents/:documentId/signing-url.

import { TurboSign } from '@turbodocx/sdk';

// 1. Create the request: an external_idv signer, no signing-link emails.
const { documentId, recipients } = await TurboSign.sendSignature({
  file: contractPdf,
  documentName: 'Account Agreement',
  sendEmail: false,
  recipients: [{
    name: 'Jane Doe',
    email: 'jane@example.com',
    signingOrder: 1,
    identityVerification: {
      mode: 'external_idv',
      provider: 'your-idv-vendor',
      maxAgeMinutes: 60,
    },
  }],
  fields: signatureFields,
});

// 2. After your vendor verifies Jane, assert the result.
const { url, expiresAt } = await TurboSign.createSigningUrl(documentId, {
  recipientId: recipients![0].id,
  identityAssertion: {
    provider: 'your-idv-vendor',
    verificationId: idvResult.id,
    verifiedAt: idvResult.completedAt, // ISO 8601
    subjectEmail: 'jane@example.com',
    method: 'id_document_liveness',
    evidenceUrl: idvResult.recordUrl, // https only
  },
  returnUrl: 'https://app.example.com/signed',
});

// 3. Open url in your iframe, a redirect, or a new tab before expiresAt.

What does TurboSign check before it issues the link?

TurboSign trusts your backend to run the verification, so it is strict about the claim itself. 8 checks run on every signing URL request for an externally verified signer, and each one fails closed with a named error.

The URL itself is single use. Once a signer opens it, a second open is refused, and minting a new URL for the same signer revokes the previous one.

Which verification method should you record?

The optional method field tells a reviewer how your vendor verified the signer. Pick the value that matches what actually ran:

assuranceLevel is a free-text label for what your vendor attests, such as an identity assurance level from NIST SP 800-63 or an eIDAS level (see our European e-signature compliance page). TurboSign records the label you send; it does not certify the level itself.

Frequently asked questions