V-PIN Webhook

Receive notifications when Veratad merges, splits, or retires V-PINs and learn how to verify webhook signatures.

Status

Purpose

Notify customers when Veratad determines that multiple V-PINs refer to the same individual and consolidates them into a single canonical V-PIN, when an issued V-PIN must be split because it was assigned to multiple distinct people, or when a V-PIN is retired after being linked to fraudulent activity.


High-Level Overview

When a client is returned a V-PIN in any request across all Veratad services, that V-PIN is automatically added to a monitor for that client. If future intelligence indicates that multiple V-PINs actually represent the same person, Veratad will merge them and publish a vpin.merged webhook event to subscribed endpoints. If we later discover that a single V-PIN was used for more than one individual, Veratad will split it into distinct V-PINs and emit a vpin.split event that lists the replacements. If a V-PIN is determined to be synthetic or tied to a fake identity, Veratad will retire it and emit a vpin.retired event.

Customers should treat the canonical V-PIN as the ongoing identifier and migrate all references from the superseded V-PIN(s) to the canonical V-PIN. Retired V-PINs should be purged from systems and not used in future transactions.


Event Model

Event Types

  • vpin.merged — Sent when one or more V-PINs are merged into a canonical V-PIN.

  • vpin.split — Sent when a V-PIN is split into multiple replacement V-PINs.

  • vpin.retired — Sent when a V-PIN is permanently retired due to confirmed or suspected fraud.

  • vpin.merge.reverted — Sent if a prior merge is undone.

  • vpin.retire.reverted — Sent if a previously retired V-PIN is reinstated.

vpin.merged is required for monitoring. Other events, including vpin.split and vpin.retired, are opt‑in.

Event Envelope

All webhook deliveries share a standard envelope for parsing and idempotency.

  • id — Unique event id used for idempotency.

  • version — Semantic version/date of payload contract.

  • trace.correlation_id — Stable id for cross-system troubleshooting.


vpin.merged — Payload Contract

  • canonical_vpin — V-PIN that survives after the merge; use this going forward.

  • superseded — Array of V-PINs that should no longer be used.

  • effective_at — Timestamp from which the merge is authoritative.

  • reason — Machine and/or human justification. Common codes include NEW_DATA_AVAILABLE, HUMAN_REVIEW, and AI_AGENT_REVIEW.

  • actions.redirect_window_days — Period during which Veratad will auto-resolve superseded V-PINs.

  • actions.resolution_endpoint — Companion API to resolve any historical V-PIN to the canonical V-PIN.

  • actions.replay_from — Earliest recommended timestamp to re-key historical records, if needed.


vpin.split — Payload Contract

  • source_vpin — The V-PIN that previously represented more than one person.

  • replacements — Array of new V-PINs to use going forward. Metadata is masked to protect PII and help route each record to the correct subject.

  • effective_at — Timestamp from which the split mapping is authoritative.

  • reason — Machine and/or human justification for the split. Common codes include COLLISION_DETECTED, HUMAN_REVIEW, and AI_AGENT_REVIEW.

  • actions.resolution_endpoint — Use to resolve existing references to the correct replacement V-PIN.

  • actions.superseded_vpin_status — Expected disposition of the original V-PIN (for example, retired).


vpin.retired — Payload Contract

  • vpin — V-PIN that has been retired and should no longer be used.

  • retired_at — Timestamp from which the retirement is authoritative.

  • reason — Machine and/or human justification for retirement. Examples: HUMAN_REVIEW, AI_AGENT_REVIEW, EXTERNAL_DATA_CONFLICT.


Resolution API

Resolve any V-PIN to its current canonical V-PIN or understand how to handle a split.

GET /v1/vpin/resolve/{vpin}

Response 200

Response 404

Response 409 (V-PIN was split)


Webhook Delivery Mechanics

Registration

Include your API token in the Authorization header when registering.

POST /v1/vpin/webhooks/subscriptions

Headers

  • Authorization: Bearer {api_token}

Request

Response 201

Security & Signing

All webhook requests are signed with an HMAC SHA‑256 using your subscription secret.

Headers

  • X-Veratad-Signature — Hex digest of HMAC SHA‑256 over body, using the subscription secret.

  • X-Veratad-Timestamp — Milliseconds since epoch when the signature was computed.

  • X-Veratad-Event-Id — Same as envelope id for idempotency.

Signature Base String

Compute HMAC_SHA256(secret, base_string) and compare (constant‑time) to X-Veratad-Signature.

Replay Protection

Reject requests where abs(now - X-Veratad-Timestamp) > 5 minutes.

Example: Verifying Signature

Retries & Ordering

  • Retries: Up to five attempts with exponential backoff (1m, 5m, 15m, 60m, 120m).

  • Idempotency: Use X-Veratad-Event-Id to dedupe. We may deliver an event more than once.

  • Ordering: Best-effort in-order per subscription; do not rely on strict global ordering.

Response Expectations

Return 2xx to acknowledge receipt. Any non‑2xx will be treated as a failure and retried.


Consumer Responsibilities

  1. Verify signature on every request.

  2. Deduplicate using the event id.

  3. For vpin.merged events, migrate references from superseded[].vpin to canonical_vpin.

  4. For vpin.split events, evaluate the replacements[] payload and re-key impacted records to the correct new V-PIN; archive or retire any lingering references to source_vpin.

  5. Update caches and any identity graphs keyed by V-PIN.

  6. Optionally re-key history from actions.replay_from if your use case requires.


Change Management & Versioning

  • The envelope version and the vpin event payloads (e.g., vpin.merged, vpin.split, vpin.retired) may evolve. Backwards-compatible changes include new optional fields.

  • Breaking changes will increment the MAJOR version (e.g., 2026-01-01) with 90 days’ notice.


Examples

Merge of Two V-PINs

Request (from Veratad to your webhook)

Expected Handler Response

Split of a Shared V-PIN

Request (from Veratad to your webhook)

Expected Handler Response

Retirement of a V-PIN

Request (from Veratad to your webhook)

Expected Handler Response


Test & Sandbox

Use these endpoints to validate your integration.

  • Send test event: POST /v1/vpin/webhooks/subscriptions/{id}:test with { "type": "vpin.merged" }, { "type": "vpin.split" }, or { "type": "vpin.retired" } to receive a mock delivery.

  • Replay live event: POST /v1/vpin/webhooks/events/{event_id}:replay re-delivers a historical event to your endpoint (authorization required).


Changelog

  • 2025-09-10: Early access release.

Last updated