Practice Submission, Callbacks and Record Lookup with Synthetic Sandbox Scenarios
Backend engineers integrating identity onboarding or signup checks need a way to exercise the callback path, persist pending state, and look up the resulting record before any real person submits documents. The sandbox provides synthetic scenarios that simulate the full flow without creating a live verification session. This article walks through the documented workflow from the published operating instructions: signing in as a merchant, submitting a synthetic check, handling the different behaviors for phone and identity scenarios, simulating outcomes for identity checks, and locating the record to inspect test usage. Every step described here comes from the official help document; no live provider calls, real identity approvals, or production permissions are involved.
curl -I https://gridzen.ai/help/sandbox/Prerequisites and Entry Point
The documented workflow begins with a single prerequisite: sign in as a merchant and use only the supplied synthetic scenarios. The entry point is the console path /console/#/verify. This is not a generic onboarding trial; it is a specific, published operating environment where the merchant context and environment filters determine whether a record appears. If no record shows up, the troubleshooting guidance says to check the merchant, environment, and filters while keeping the original ID. No account creation, API key provisioning, or live service activation is described in this document. The sandbox is explicitly a practice environment, and the document states that a simulated result is not a live identity approval.
Starting a Synthetic Verification
From the entry point, choose New verification. Select either phone or identity as the check type, then pick one of the supplied synthetic scenarios and submit once. The document notes that a record with an ID appears immediately after submission. For phone scenarios, synthetic signals are normally returned directly at this stage. For identity scenarios, the initial state is pending and requires an additional simulation step. The ID that appears is the key reference for the rest of the workflow; the troubleshooting section emphasizes keeping the original ID while waiting or investigating. No callback endpoint configuration, webhook registration, or network request to a provider is documented here. The submission is a console action that creates a synthetic record.
Phone Scenario Behavior
When a phone synthetic scenario is submitted, the document states that synthetic signals are normally returned directly. This means the record moves from submission to a completed synthetic state without further console interaction. The record ID remains the anchor for later lookup. The document does not describe any simulation action, polling, or callback waiting for phone scenarios. It also does not specify what the synthetic signals contain, only that they are returned directly. This behavior contrasts with identity scenarios, which require an explicit simulation step. Engineers should not assume that phone scenarios exercise a callback path; they are a simpler synthetic path that returns signals immediately in the console record.
Identity Scenario Simulation
For identity synthetic scenarios, the workflow diverges. After submission, the record shows a pending state. The documented steps are: open the record, use its simulation action, then refresh the same record. The selected simulated outcome replaces the pending state. The document instructs to keep the ID while waiting. This simulation action is a console operation, not a callback from an external provider. No webhook delivery, signature verification, or provider polling is described. The simulation replaces pending with a synthetic outcome such as Approved or Declined, but the done statement makes clear that this simulated result is not a live identity approval. The record now holds a synthetic outcome that can be inspected like any other record.
Locating and Inspecting the Record
After submission (and simulation for identity), the next documented step is to open Records, locate the ID, then inspect test usage under Usage and billing. The document states that list and detail views show the same record, labelled sandbox or synthetic. This labeling is the visual indicator that the record belongs to a practice run. The inspection of test usage under Usage and billing is the documented completion check. No API call to retrieve the record, no programmatic filtering, and no export function are described. The workflow is entirely console-based: submit, optionally simulate, then find the record in the Records view and examine its usage metadata. The original ID kept from submission is the lookup key.
Understanding Synthetic Results
The done statement in the document is explicit: reopen the record and recognize that a simulated result is not a live identity approval. This is the critical boundary for engineers. The sandbox exercises the record lifecycle, ID tracking, console navigation, and usage labeling. It does not exercise a live provider callback, a signed notification, an authoritative retrieval, or a real permission grant. The troubleshooting note reinforces that if no record appears, the issue is merchant, environment, or filter configuration — not a provider failure. The synthetic scenario is a rehearsal of the console workflow and record lookup, not a verification of a real person. Any integration code that depends on callback handling, state persistence across restarts, or deadline enforcement must be tested separately using the synthetic examples that explicitly model those behaviors.
Inspect the documented workflow
https://gridzen.ai/help/sandbox/ · Read the prerequisites, permissions, steps and completion checks. This article does not execute a verification or activate a service.
Sources and scope
https://gridzen.ai/help/sandbox/ https://gridzen.ai/guides/current-capabilities/ Based on published operating instructions; no service execution or live availability was tested. Based on the checked source snapshot; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.
Separately try three sandbox outcomes Create an account to continue integrating
A download does not prove a successful run. Local examples and the online sandbox are tested separately.