Developers · Sandbox access

Use sandbox planning to turn technical interest into a structured enterprise evaluation path.

This page explains how OMINEX approaches sandbox access and technical evaluation. The point is not self-serve trial software for anonymous users. The point is a buyer-specific review path that helps enterprise teams validate fit, architecture, and integration boundaries before production rollout.

Continue technical review

Move from sandbox planning into the adjacent diligence path you need.

Use the other Developer Trust Center destinations to inspect claims, proof surfaces, delivery behavior, and downstream verifier workflows as part of the same evaluation model.

Developer Trust CenterStart with the full technical evaluation path for ERC-3643 integration, delivery surfaces, verifier workflows, and sandbox review.ERC-3643 claimsSee how OMINEX integrates with ERC-3643-compatible workflows without becoming the compliance decision-maker or universal gatekeeper.Transparency log verificationReview how provenance, revocation state, and public proof references support technical and diligence workflows.Webhooks and deliveryUnderstand signatures, retries, event delivery, and how normalized attestations move into customer systems.Verifier workflowsSee how tokenization platforms, issuers, and compliance teams consume attestations operationally without centralizing PII.API and webhook docsMove from the evaluator overview into the broader API and operational reference materials.Architecture and conceptsUnderstand the normalization model, system boundary, and downstream integration posture across the stack.

Why this exists

Enterprise teams usually need a guided technical evaluation, not a generic product trial.

Sandbox access should help buyers confirm how OMINEX fits their existing provider stack, what proof surfaces matter first, and how the platform can integrate into ERC-3643-compatible workflows without rewriting their decision model. That makes the sandbox a procurement-aware technical path rather than just a demo environment.

Example sandbox request

POST /v1/sandbox/evaluations
content-type: application/json
x-ominex-org: org_demo

{
  "company": "Issuer Demo Capital",
  "primaryUseCase": "tokenized fund onboarding",
  "providers": ["provider_kyc", "provider_aml"],
  "evaluationGoals": ["erc3643", "webhooks", "transparency_log"],
  "stakeholders": ["engineering", "compliance", "security", "procurement"],
  "targetTimeline": "45_days"
}

Architecture and control review

Map the existing provider stack, decision systems, tokenization surfaces, and trust assumptions so the evaluation starts from the customer’s real operating model.

Sandbox scope definition

Choose which proof surfaces to evaluate first, such as ERC-3643-compatible claims, APIs, webhooks, Verifiable Credentials, or transparency-log verification.

Buyer-specific success criteria

Define what technical, compliance, and procurement stakeholders will need to see before the team can move into trust review, commercial scoping, or deployment planning.

Request field

Type

company

Names the evaluating organization so the sandbox plan can stay buyer-specific.

string

primaryUseCase

Describes the operational flow under review, such as onboarding, transfer, or servicing.

string

providers[]

Lists the upstream decision providers that will remain authoritative during evaluation.

array

evaluationGoals[]

Defines which technical surfaces the buyer wants to inspect first.

array

stakeholders[]

Makes cross-functional approval requirements explicit before technical review begins.

array

Example sandbox response

{
  "evaluationId": "eval_01J...",
  "status": "discovery_pending",
  "recommendedTracks": ["erc3643", "webhooks", "trust_review"],
  "requestedArtifacts": ["architecture_walkthrough", "security_pack"],
  "nextStep": "schedule_architecture_review",
  "owner": {
    "team": "solutions_engineering",
    "sla": "2_business_days"
  }
}

Expected sandbox artifacts

Reference flows

Walk through how upstream provider outcomes enter OMINEX and move into customer-controlled verification or tokenization systems.

Boundary clarification

Confirm where OMINEX stops, where upstream providers remain authoritative, and where customer trust policy takes over.

Cross-functional alignment

Give product, engineering, compliance, and procurement teams a shared model before deeper diligence begins.

Response field

Type

evaluationId

Stable identifier for the structured evaluation plan.

string

status

Shows where the sandbox process sits in the review lifecycle.

enum

recommendedTracks[]

Routes the team into the most relevant technical and trust review paths.

array

requestedArtifacts[]

Lists the materials the buyer will receive or review next, such as architecture walkthroughs or a security pack.

array

owner

Identifies the team responsible for the next stage of guided evaluation.

object

Next step

A strong sandbox path should connect directly to trust review and rollout planning.

The technical evaluation becomes more valuable when it also answers trust, procurement, and operational questions. That is why sandbox planning should connect directly to the Trust Center and the buyer’s implementation workflow.

Request sandbox access Open security-pack path

Cross-functional stakeholders should be able to use the same evaluation path.

The sandbox should validate integration boundaries before deeper implementation work begins.

Technical success criteria should be explicit enough to support procurement and rollout decisions.

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.

Schedule buyer review Licensing & IP