Skip to main content
Persona

Persona's Inquiries API → the Naive verification primitive

Persona gives you a hosted KYC flow: author an inquiry template, POST /api/v1/inquiries, hand the subject a verification link, and read the result (ID scan, selfie, database checks) back as an inquiry status or webhook. It does that job well, and the API is mature. But it is also a separate vendor account:
  • KYC lives behind its own API key, its own templates and themes, and its own dashboard — disconnected from wherever the verified person’s company, cards, phone, and secrets live.
  • An inquiry’s reference-id is a string tag back to a row in your user table. Persona knows the person passed KYC; it does not know that same person is the responsible party who then incorporates the company and owns its virtual card.
  • “This founder cleared KYC — now what is allowed to happen on their behalf?” is answered in Persona for verification, and in unrelated systems for formation, banking, and cards. The cleared identity has no shared accountability with the rest of the company’s footprint.
Naive’s verification primitive gives the same capability — hosted KYC for one or more company founders, with real-time status — but the person you verify is a governed identity, not a tagged inquiry:
  • The tenant user whose founders you KYC is the same identity that then forms the LLC, and owns its cards, phone number, email inboxes, and vault secrets.
  • Verified PII (SSN, DOB, address) is pulled from the encrypted identity vault at formation time — it never lands in your database.
  • When every member passes, ready_for_formation flips to true — KYC is structurally a step toward incorporation, not an isolated pass/fail you have to wire to a formation vendor yourself.
This guide maps Persona’s Inquiries API to Naive’s, shows the smallest working swap, and is explicit about what does not map yet.
Persona is a trademark of its owner, used here for identification only. No endorsement or affiliation is implied.
Scope this migration before you start. Naive’s verification primitive is founder / responsible-party KYC ahead of company formation — the people who own and form the company.
  • If you use Persona to verify founders before incorporation, this is a clean migration and the consolidation win is real.
  • If you use Persona to KYC your end users / customers at scale — arbitrary subjects, custom templates, AML/watchlist Reports, manual-review Cases — that does not map to Naive today. Keep Persona for that. See what doesn’t map yet.
Tested against: the Persona REST API (base https://api.withpersona.com/api/v1, header Persona-Version: 2025-10-272025-12-08 also valid — hosted flow at https://inquiry.withpersona.com, docs snapshot June 2026), and the Naive Node SDK @usenaive-sdk/server against the Naive API (base https://api.usenaive.ai/v1, docs snapshot June 2026).Version notes:
  • Persona’s officially featured SDKs are client-side (persona-react / persona-web / mobile); the server-side integration is REST, which is what the “before” code below uses. There is no first-party server SDK to swap out.
  • Persona verifies one subject per inquiry against a template you author (itmpl_…). Naive verifies a set of company members in one verification.start call, and requires ownership_percentage to sum to 100, exactly one role: "primary", and exactly one is_responsible_party: true. This is formation-shaped — see gaps.
  • Persona is webhook-first (inquiry.completed / inquiry.approved / inquiry.declined). Naive’s public webhook surface advertises only email.received, sms.received, and approval.resolved today, so KYC status comes from the validation-token complete endpoint (instant for the primary) + polling GET /v1/verification/:id. Treat GET /v1/webhooks/event-types as the source of truth before depending on any KYC event.

Concept map

Before / after: the core path

The path that matters for founder KYC is start verification for the people who own the company, hand them a hosted link, then know when they’ve passed. Here it is on both platforms.
The shape lines up closely. The real differences to plan for:
  • One subject vs. a set of members. Persona’s inquiry is one person tagged with a reference-id. Naive’s start takes the founding members with ownership_percentage (must sum to 100), one primary, and one is_responsible_party. That structure is the formation contract — not an arbitrary KYC subject.
  • The link comes back inline. Persona is create inquiry → generate link → email it yourself. Naive returns primary_link from start and emails secondary members automatically.
  • Status: poll + validation token, not a webhook. Persona steers you to inquiry.completed webhooks. Naive’s public webhook surface does not advertise a KYC event today — use the validation-token complete (instant for the primary) and poll verification.get for the rest.
  • The id is your identity, not a tag. In Persona, reference-id points back to your DB. In Naive, forUser(id) is the identity that owns the founders’ KYC and the company they’re about to form, its cards, phone, and vault.

Knowing when a founder passed

  • Persona’s recommended path is a webhook workflow: subscribe to inquiry.completed, then approve in a post-inquiry workflow and act on inquiry.approved.
  • Naive’s reliable public path today is validation token + polling:
  • Member statuses map roughly as: Persona completed/approved → Naive pass; declined/failedfail; needs_reviewpending_review; pending/createdin_progress / link_sent. See the full status list.

Minimal viable migration

The smallest swap that keeps a working founder-KYC flow running is just start + hand over the link + read status.
1

Install the SDK and set your key

Set NAIVE_API_KEY (a server-side key from the dashboard).
2

Swap inquiry creation for verification.start

Replace POST /api/v1/inquiries (one subject + template) with client.verification.start({ members: [...] }). Provide each founder’s name + email, ownership_percentage (summing to 100), exactly one role: "primary", and exactly one is_responsible_party: true. Drop the inquiry-template-id — the KYC playbook is managed for you.
3

Swap link delivery

Drop generate-one-time-link + your own email send. Hand the returned primary_link to the primary founder; secondary members are emailed automatically. Use verification.resend if a link expires.
4

Swap status tracking

Replace the inquiry.completed webhook with the validation-token complete call for the primary (instant) and poll GET /v1/verification/:id for the rest. Gate on ready_for_formation instead of an inquiry.approved workflow.
5

Ship it

At this point your founder-KYC flow runs on Naive. Everything below is upside — the same identity is now ready to form the company and own its cards, phone, email, and vault.

Consolidate further once you’re on Naive

This is where the migration pays for itself. In Persona, an inquiry verifies a person and stops there — incorporation, banking, cards, and phone all live in separate systems keyed off a reference-id string. On Naive, the verified founders are the identity that carries straight into formation and every downstream primitive.

Gain #1 — one identity across primitives

  • With Persona, KYC is an island: an inquiry tagged with a reference-id that you manually re-key into your formation, banking, card, and phone vendors.
  • With Naive, naive.forUser(acme.id) is a single handle to KYC and formation and cards and phone and email and vault. The founders you verified are literally the responsible party the company is formed under — demonstrated by formation.submit({ verification_id }), which requires that the KYC passed.

Gain #2 — execution-time permission enforcement

  • Whether an agent may start KYC at all is policy on the Account Kit, enforced at execution time — not a Persona API-key scope you manage separately.
  • The agent’s code is identical either way — client.verification.start({ ... }). Whether the call runs is decided at execution time:
    • An agent whose kit gates verification.start gets 202 { status: "pending_approval", approval_id } instead of starting KYC. A human approves it and KYC begins on replay — see the start endpoint note.
    • This is the same approval model that gates formation.submit, cards, and domains.purchaseone policy surface, not one per vendor.

Gain #3 — unified accountability

  • Every KYC start, completion, link resend, and the formation it gates lands in one per-user activity log — alongside the company’s card, phone, email, and vault events, not in a separate Persona dashboard:
  • That is the question that is hard to answer when KYC lives in Persona, incorporation in Stripe Atlas, and cards in Stripe Issuing. Under Naive it is a single query.

What does not map yet

A migration guide that hides gaps is worse than none. Founder KYC (start → hosted link → status → formation gate) maps cleanly, but the following Persona capabilities have no direct equivalent on Naive’s verification primitive today. Check this list against your app before you commit.
The single most important gap: Naive does not do general-purpose end-user KYC. If your Persona usage is verifying your customers (not your company’s founders), or you depend on AML/watchlist Reports, a manual-review Cases queue, custom templates, or KYC webhooks, those are the gaps most likely to matter — Naive verifies founders ahead of formation and gates on ready_for_formation. Equally, note the direction of the model: Persona verifies a tagged subject and stops; Naive verifies the founders and carries that same identity into formation, cards, phone, and vault. That carry-through is the consolidation gain — but it means the primitive is shaped for incorporation, not for verifying arbitrary people.

Where to go next