The downloadable Website Integration Kit for any non-WordPress site, the WordPress plugin, platform REST APIs, SDKs and webhooks, all behind scoped credentials and one audit trail. Working integrations are marked as such; platform-level examples are labelled clearly.
Each registered application receives two credentials. The App ID (ca_live_…) identifies your registered application and domain. The App Secret (sk_live_…) is the secret your server-side integration uses to perform privileged operations. The App ID alone is not a bearer secret and does not authorise privileged calls.
The App Secret must remain on your server. Never place it in HTML, browser JavaScript, mobile application code, public source control, public logs, screenshots or public support tickets. In WordPress, credentials are entered once in the Confrmo settings screen and the plugin keeps them server-side. In the Website Integration Kit below, they live in a protected server environment file read only by the Node.js proxy.
Server-side .env
# Issued per registered production domain. Server-side only.
CONFRMO_APP_ID=ca_live_… # identifies the application
CONFRMO_APP_SECRET=sk_live_… # privileged secret, never in the browser
Sandbox equivalents (ca_test_) exercise the full flow against test identities without touching production. Credentials are scoped per environment and revocable.
REST API
Platform-level example. The endpoint below illustrates the shape of the Confrmo verification API and is not the installation method for the downloadable Website Integration Kit; the kit ships its own server proxy and same-origin routes, documented in the Website Integration Kit section.
Verify the human at the moment of action with a single call. The response is a decision, the contributing signals and a signed proof token you can store or forward.
Platform-level example. The snippet below illustrates the planned @confrmo/web SDK surface. It is not included in, and is not the installation method for, the downloadable Website Integration Kit. To add Confrmo Connect or Confrmo: It’s You to a non-WordPress website today, use the Website Integration Kit below, which contains the working browser assets and server proxy. Native iOS and Android SDKs embed capture, liveness and the VCode scanner inside your own apps.
JavaScriptiOSAndroid
import { Confrmo } from'@confrmo/web';
const confrmo = new Confrmo({ appId: 'ca_live_…' });
const result = await confrmo.verify({
action: 'checkout',
policy: 'step-up'
});
if (result.status === 'approved') proceed();
Website Integration Kit
Add Confrmo Connect and Confrmo: It’s You to any website without WordPress.
Confrmo Connect provides passwordless sign-in through a secure VCode and approval in the Confrmo app. Confrmo: It’s You allows a customer to approve a temporary live view of a verified document. The document is not transferred to or retained by the integrating website.
The integration kit includes browser assets, a secure Node.js server proxy, nginx and PM2 examples, deployment instructions, security requirements and acceptance tests. Your organisation receives a domain-specific App ID and App Secret. The App Secret remains on your server and is never placed in browser code.
The website creates a short-lived login session through its server. The browser displays a Confrmo VCode. The user scans the VCode and approves the request in the Confrmo app.
After approval, the customer’s server consumes the session once and receives a pairwise user handle. The customer maps that pairwise handle to its own local account and creates its normal authenticated session.
The browser must never receive the Confrmo App Secret or the underlying Confrmo session ID.
Website
Customer server
Confrmo login session
VCode displayed
User scans the VCode
Confrmo app approval
Customer server consumes approval once
Pairwise user handle
Local authenticated account
The pairwise user handle must only be trusted when returned by the server-side consume operation. A browser-supplied handle must never be treated as authenticated.
The supplied reference demonstration uses short-lived in-process session storage. Production deployments using multiple application instances must replace this with Redis or an equivalent expiring shared store.
Confrmo: It’s You
Confrmo: It’s You enables a customer-approved temporary view of a verified document.
The website starts a viewing session through its server. The customer scans the session VCode and receives the document request in the Confrmo app. The customer explicitly approves or declines access.
When approved, the server claims the one-time viewing token and the browser displays the temporary verified view. The integrating website must not download, cache, persist, analyse or silently copy the document. The view must be removed immediately when either party ends the session.
Website starts viewing session
Customer scans the VCode
Website requests a document
Customer approves or declines
Temporary verified view appears
Either party ends the session
Displayed data is immediately removed
Confrmo: It’s You must be enabled for the customer’s registered App ID before document viewing sessions can be created.
Privacy. The document remains under the customer’s control. It is displayed only after explicit approval and only for the duration of the active session. Screenshot-risk reporting, where present, is a risk signal, not proof of prevention and not guaranteed blocking.
Security requirements
Keep your App Secret server-side
Your sk_live App Secret must be stored in a protected server environment or secret manager. Never include it in HTML, browser JavaScript, a mobile application, source control or public logs.
The browser should communicate only with same-origin routes provided by the customer’s server. The customer’s server then performs privileged Confrmo API operations using protected credentials.
Integration requirements
Node.js 20 or later
HTTPS-enabled production domain
Server-side environment configuration
Domain-specific Confrmo App ID and App Secret
Confrmo: It’s You permission when document viewing is required
Persistent shared session storage for multi-instance production deployments
nginx or an equivalent HTTPS reverse proxy
A local customer-account mapping strategy for Confrmo Connect
The supplied reference demonstration uses short-lived in-process session storage. A production deployment using multiple application instances should use Redis or an equivalent expiring shared store.
Try the Live Demos
To test these demonstrations, install and sign in to the Confrmo app, then use the Scanner tab to scan the displayed VCode.
WordPress WordPress Integration Demos
These demonstrations show Confrmo operating through the production WordPress integrations on confrmo.com.
WordPress
Confrmo Connect — WordPress
Experience passwordless website sign-in through the Confrmo WordPress integration. Display the VCode, scan it using the Confrmo app and approve the sign-in.
These demonstrations use the downloadable non-WordPress website integration, with credentials and privileged API operations protected by a standalone server-side proxy. They are not WordPress plugins.
Standalone
Confrmo Connect — Standalone Website
Experience passwordless sign-in using the standalone website integration. No WordPress installation is involved.
Site owners configure everything from the admin, see Confrmo for WordPress. For developers, shortcodes expose each flow directly in templates and page builders.
WordPress
<!-- Verified human login (replaces wp-login) -->
[confrmo_login]
<!-- Gate paid or restricted content -->
[confrmo_protectrole="member"] … [/confrmo_protect]
<!-- Verify before a sensitive action -->
[confrmo_verifyaction="checkout"] … [/confrmo_verify]
<!-- Display a VCode anywhere -->
[confrmo_vcode]
Webhooks
Subscribe to decision and ownership events for flows that resolve out of band. Every delivery is signed; verify the signature header before trusting the payload.
Webhook
// POST to your endpoint
{
"event": "verification.approved",
"action": "payment.release",
"proof": "cfp_…",
"occurred_at": "2026-07-08T12:04:11Z"
}
// Also: verification.blocked, verification.step_up,
// ownership.assigned, ownership.confirmed, ownership.transferred
VCode
Generate a VCode for any record: a login session, an asset, a certificate or a document. The VCode resolves to the live record; the register code is its human-readable fallback.
REST
POST https://api.confrmo.com/v1/vcodes
{ "subject": "asset", "asset_ref": "ast_2210" }
// 200 OK
{
"vcode_number": "VC-8842-1907",
"register_code": "3F8N-KX2VQ7-TD",
"image_url": "https://…/vcode.png"
}
// Lookup: resolve any VCode or register code to its live recordGET https://api.confrmo.com/v1/lookup/3F8N-KX2VQ7-TD
Ledger APIs
Register assets, issue certificates and read live records on the Confrmo Ledger. Every write is signed and appended to the record's audit trail; public verification is free at ledger.confrmo.com.
REST
POST https://api.confrmo.com/v1/ledger/assets
{
"name": "1962 Omega Seamaster",
"category": "watch_jewellery",
"serial_number": "145.022-69"
}
// The response seals the record: register code,
// VCode, signature and an empty audit trail.
Ownership APIs
Assign ownership at issuance, create transfer offers addressed to a verified user and trigger live ownership checks that the owner answers from the Confrmo app.
REST
// Offer an asset to a verified userPOST https://api.confrmo.com/v1/items/offers
{ "asset_ref": "ast_2210", "offered_by": "Northbank Auctions" }
// Ask the owner to confirm, livePOST https://api.confrmo.com/v1/items/pings
{ "asset_ref": "ast_2210" }
// The certificate shows the response and time,
// e.g. "Owner confirmed in 4.2s"
Error handling
Errors are ordinary JSON with a stable code, an HTTP status that means what it says and a human-readable message. Retry 429 and 5xx with backoff; treat 4xx as yours to fix. Verification declines are not errors: a blocked decision arrives as a 200 with the reasons in the payload.
REST
// 401 unauthorized
{ "error": { "code": "invalid_api_key", "message": "Unknown or revoked key." } }
// 429 too many requests, includes Retry-After header
{ "error": { "code": "rate_limited", "message": "Slow down." } }
// 422 unprocessable
{ "error": { "code": "unknown_action", "message": "Action not defined in policy." } }
Security model
Your systems never touch biometrics. Enrolment and matching happen within Confrmo and on the user's trusted device; your integration receives decisions and signed proof tokens. Every proof and webhook delivery is signed, so authenticity is verifiable independently of transport. API keys are scoped per environment and capability and are revocable instantly. Ledger records are tamper-evident: every write is signed and appended to the audit trail, and a record that fails signature validation is flagged on its public certificate. Read the full architecture on the Security & Compliance page.
