Skip to content

Delivery patterns

The same form and the same Decision Flow power all three. What changes is who opens the link, and where it opens.

Link/QR API link WebView
API token Not needed Required Required
Where it opens Hosted form Hosted form In your app
Result via Portal¹ Webhook, Portal Webhook, Portal

¹ Plus the webhook, if one is configured.

1 · Share a link or QR code

Take the form’s public entry URL from the Portal and send it — email, SMS, LINE, or a printed QR at a counter. Your team reviews submissions in the Portal.

Use when you want to be live today, are piloting a flow, or the volume does not justify engineering time. Zero code, no API token.

2 · Create via API, then share the link

Your backend calls Create an application and gets a form_url belonging to one applicant. Behaves like pattern 1, except your system triggers it, you can pre-fill known data, and the result ties back to your record via slug.

Use when verification is triggered by an event in your system — a new account, a payout above a threshold, a periodic re-KYC.

3 · Embed in a mobile WebView

Create the application, then load form_url in a WebView / WKWebView inside your app. The applicant never leaves your product; camera capture, liveness and OCR all run in the embedded view.

Use when you have a native app and want a white-labelled journey. Grant camera permission and enable allowsInlineMediaPlayback on iOS.

Patterns 2 and 3 let you pre-fill known data so the applicant types less. Pre-filling happens in the create call and nowhere else — send everything you already hold in the answers of POST .../create/. There is no endpoint for adding answers to an existing application.

{
"answers": {
"ekyc_document_type": "passport",
"name_prefix": "Mr.",
"gender": "M",
"date_of_birth": "1990-01-15",
"home_address_country": "THA"
}
}

Two rules:

  • Keys must be real fields on the form, or declared as input parameters — see Set up your workspace.
  • Values are validated for format even on a draft. See Validation.