Docs / Getting Started
Integration onboarding that moves customer teams from first webhook delivery to verification-ready read paths.
This guide frames the expected OMINEX integration sequence for partner engineering teams, compliance operations, and platform owners who need to operationalize provider evidence intake and customer-facing verification endpoints with minimal ambiguity.
Start with the operating model, then connect provider delivery, queue execution, and customer verification reads deliberately.
OMINEX works best when teams separate evidence collection from attestation computation and downstream verification. The onboarding sequence below is designed to keep integrations clear, auditable, and resilient under production traffic.
Recommended rollout
Step 1
Provision the tenant boundary
Create the organization context, define the governing rule set, and register the provider connection that will send evidence into OMINEX.
Step 2
Attach provider webhook delivery
Point each provider to its organization-scoped webhook path so evidence can land asynchronously without blocking downstream verification reads.
Step 3
Process evidence into snapshots
Run queue-backed processing to normalize records, evaluate rule logic, and produce a verification-ready attestation snapshot.
Step 4
Read through the verification surface
Use indexed lookup for fresh subject reads or direct snapshot verification when partner systems already store the snapshot public identifier.
Reference surface
The first implementation conversations usually center on four operational endpoints.
Authentication model
Integration traffic should be scoped to organization-owned provider connections and downstream customer agreements rather than end-user sessions.
Traffic model
High-volume consumers should cache snapshot reads aggressively and treat indexed lookup as a fresh-read convenience instead of a polling primitive.
Operational separation
Evidence intake, processing, and verification should stay decoupled so retries, queue backlogs, and downstream reads remain operationally manageable.
1. Create organization and rule-set boundary
2. Provision provider connection + webhook path token
3. Send evidence into POST /api/webhooks/providers/{token}
4. Drain queue via POST /api/processing/jobs/run-next
5. Store snapshot public IDs after evaluation completes
6. Serve downstream reads through GET /api/verification/snapshots/{snapshotPublicId}Continue into implementation planning
Once the operating sequence is clear, teams typically move next into customer-specific use cases and commercial onboarding so engineering and go-to-market planning stay aligned.
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.