VettiGuard

Trust Journey Browser SDK

Embed a policy-driven verification experience with one JavaScript file while your application backend remains responsible for private secrets, subject context, and final authorisation.

The browser never receives a VettiGuard private secret

The Journey SDK calls authenticated endpoints in your own application. Those endpoints start and verify the journey server-to-server using the VettiGuard private secret. The browser receives only short-lived journey data and response proofs.

Single-file clienthttps://vettiguard.com/assets/journey.js

Mount the journey interface

<div id="transaction-verification"></div>

<script src="https://vettiguard.com/assets/journey.js"></script>
<script>
const journey = VettiGuardJourney.mount({
  container: '#transaction-verification',
  brandName: 'Example Bank',
  title: 'Approve this transfer',
  journeyKey: 'transaction-approval',
  action: 'approve-transfer',
  consentVersion: '2026-08',

  startUrl: '/api/security/journey/start',
  verifyUrl: '/api/security/journey/verify',
  statusUrl: '/api/security/journey/status',
  escalateUrl: '/api/security/journey/escalate',
  statusPollMs: 15000,

  request: function () {
    return {
      pending_operation_id: document
        .querySelector('[data-operation-id]')
        .dataset.operationId
    };
  },

  methodHandlers: {
    facial_authorization: runFacialAuthorization,
    facial_liveness: runFacialLiveness,
    human_verification: runHumanVerification
  },

  onComplete: function (result) {
    submitApprovedOperation(result);
  }
});
</script>

The SDK injects its own scoped responsive styles. No stylesheet or top-level await is required.

Return a VettiGuard response token from each permitted method

function runFacialAuthorization(journey) {
  return VettiGuardFacial.authorize({
    container: '#facial-verification',
    siteKey: window.PUBLIC_VETTIGUARD_KEY,
    action: journey.action,
    intentUrl: '/api/security/facial-authorization-intent'
  }).then(function (result) {
    return result.response_token;
  });
}

Your application only needs handlers for methods enabled by the configured journey. A handler may return a token string or an object containing response_token.

Expose three small authenticated routes

POST /api/security/journey/start
POST /api/security/journey/verify
POST /api/security/journey/status
POST /api/security/journey/escalate

The start route loads the authenticated subject and pending operation from server-side records, then calls /v1/journeys/start. The verify route calls /v1/journeys/siteverify with the same subject, action, and operation reference. The optional status and escalation routes call /v1/journeys/status and /v1/journeys/escalate.

Do not trust browser context

Amounts, beneficiaries, account identifiers, subject IDs, and operation references must be derived again by your backend.

Cancel, restart, or inspect the active journey

journey.status();
journey.cancel();
journey.restart();
journey.destroy();
journey.getState();

Button-driven SDK actions handle rejected promises internally, while direct method calls still return Promises so application code can await or chain them safely.

Support interrupted and exceptional journeys

POST https://api.vettiguard.com/v1/journeys/status
POST https://api.vettiguard.com/v1/journeys/escalate

Status returns the session state, current method, attempts, expiry, and review status. Escalation creates a privacy-safe review case when your policy and business process permit assisted verification.

Keep the final business decision on the server

  • Never place the private site secret inside browser JavaScript.
  • Use authenticated, CSRF-protected application endpoints for journey creation and verification.
  • Verify the same subject, action, and operation reference used when the journey was started.
  • Do not treat manual review as a successful biometric match. It is a separate business recovery outcome.
  • Commit a transaction or sensitive change only after your backend accepts the completed journey proof.