Verification API

Ship verification reads fast without rebuilding your evidence pipeline.

OMINEX gives teams an integration surface for provider webhooks, high-volume verification requests, and durable evidence intake so product and engineering teams can move faster without forcing heavy recomputation into every customer request.

Integration surface

Verification traffic can stay fast when ingestion, processing, and lookup are separated deliberately.

OMINEX will support an integration pattern where upstream evidence enters through provider-specific webhook paths, attestation work moves through a queue-backed processing layer, and downstream customers retrieve verification envelopes through indexed lookups or direct snapshot reads.

Webhook-first

Evidence delivery can be accepted immediately and normalized into tenant-scoped records.

Queue-backed

Operational tooling can run jobs asynchronously instead of forcing heavy evaluation into the request cycle.

Indexed reads

Customer systems can resolve the latest usable attestation state through stable, query-ready envelopes.

Conceptual OMINEX verification dashboard illustration

Endpoint map

A descriptive endpoint surface for onboarding portals, compliance teams, and partner engineering groups.

Method
Path
Purpose
POST
/api/webhooks/providers/{webhookPathToken}
Accept provider evidence and create an asynchronous processing job.
POST
/api/processing/jobs/run-next
Process the next ready job from the attestation work queue.
GET
/api/verification/latest
Resolve the latest verification envelope by organization and subject lookup key.
GET
/api/verification/snapshots/{snapshotPublicId}
Read a known verification snapshot directly when the caller already stores the snapshot identifier.
Webhook evidence intake
POST /api/webhooks/providers/wh_demo_token
Content-Type: application/json

{
  "type": "applicantReviewed",
  "applicantId": "investor-001",
  "reviewResult": { "reviewAnswer": "GREEN" },
  "reviewDate": "2026-04-08T10:00:00.000Z"
}
Indexed verification lookup
GET /api/verification/latest?organizationPublicId=org_demo&externalRef=investor-001

{
  "snapshot": {
    "publicId": "snap_demo_001",
    "status": "all_rules_satisfied"
  },
  "verification": {
    "signatureValid": true,
    "outcome": "all_rules_satisfied"
  }
}

Rate-limit guidance

Customer integrations should favor snapshot caching and controlled retry behavior as traffic grows.

Webhook intake

Customer providers should batch retries conservatively and treat webhook delivery as append-oriented rather than user-blocking.

Designed to tolerate bursty upstream delivery; pair with idempotent retry logic.

Indexed verification lookup

High-volume consumers should prefer cached subject-based lookup only when they do not already have a snapshot identifier.

Use short-lived edge caching and backoff on repeated misses.

Snapshot verification

This is the preferred read path for partner systems that store snapshot public IDs after processing completes.

Lowest-cost retrieval path for repeated downstream verification traffic.

Design guidance for high-volume teams

Verification consumers should prefer direct snapshot reads whenever they already store a snapshot public ID. Indexed lookup remains valuable for fresh subject-based requests, but repeated traffic should be cached at the customer edge and retried with jitter rather than tight polling loops.

See the platform product

Provision

Customer teams can provision provider connections and organization-scoped webhook paths before onboarding live traffic.

Process

Queue execution can compute a new attestation snapshot without blocking evidence delivery or customer-facing verification reads.

Verify

Partner systems can read the latest attestation envelope through indexed lookup or resolve an exact snapshot when they already know the public identifier.

Next step

Move from product curiosity to operating-fit review.

Schedule a buyer review, ask a product question, or start a licensing conversation without digging through extra navigation layers.