身份驗證 API 逾時：在不假設已批准的情況下恢復處理

Your onboarding service created a hosted verification session, and then the answer never arrived in time. The call timed out, or the callback is late. The tempting shortcuts are to let the user through or to reject them. Neither is justified: a timeout means the check could not complete, which is neither approval nor decline. This article walks through the checked synthetic identity example, its local deadline and its explicit failure branches, so you can decide whether a sandbox integration fits your onboarding task. Search interest for this term is not measured here; unknown volume stays unknown.

The problem and the decision you face

A seller signs up, your service opens a hosted identity session, and the provider is slow, unreachable or silent. Your code must still decide what the user sees and what your application allows. The decision is not "pass or fail" but which state to record and who acts next. The GridZen provider-failures guide frames this clearly: an unavailable provider is an operational failure, not a low-risk signal. The current Twilio adapter returns a 503 through the API when its provider is unavailable, and the alpha does not silently convert that failure to allow. A review queue or authorized fallback must be implemented by your calling workflow. Keep three outcomes separate: a mismatch is a returned assertion, insufficient evidence means your policy lacks a required signal, and a technical failure means the check could not complete. Record HTTP status separately from the decision outcome; a 503 should never be logged as decline or allow.

What the checked fixture actually implements

The downloadable example is a dependency-free synthetic fixture, not a live provider adapter. Its identity part persists sessions in SQLite. Calling create stores a session with status pending and a deadline equal to now plus timeout; with the defaults (now 0, timeout 60) the deadline is 60. The returned hosted_link points at an invalid example domain, link_executable is false, and next is send_real_provider_link_only_after_authorization. The event method accepts only synthetic callbacks: mode must be synthetic_fixture and source must be fixture_callback, otherwise it raises PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. Event identifiers must start with fixture-. There is no real signature verification. An event that arrives at or after the deadline marks the session expired instead of applying its status. An unrecognized status marks it unknown rather than guessing. The recover method expires a pending, review or unknown session whose deadline has passed, purely locally: it returns provider_polled false and never contacts a provider. Any permission_granted value is a local fixture record; live_permission_changed is always false.

Worked hypothetical scenario with expected outputs

Hypothetical: a synthetic session fixture-session is created at time 0 with a 60-second timeout. The provider call times out and no callback arrives. At time 61 your worker calls recover. The tested output is: mode synthetic_fixture, session fixture-session, status expired, deadline 60, permission_granted false, grant_count 0, live_permission_changed false, policy_version 1, allow_action true, next review_or_authorized_provider_refresh, provider_polled false. Nothing was approved, and the next step points to a human review or an authorized provider refresh, not to an automatic retry that assumes success. Compare the happy path, also tested: an Approved fixture event with policy true inside the deadline yields status approved, permission_granted true, grant_count 1. Replaying the same event returns the identical record with grant_count still 1. A later Declined correction yields status declined, permission_granted false, grant_count 1. A late callback after expiry cannot revive the session, because expired is terminal for ordinary events.

Failure handling in your own design

The following is proposed application design, not implemented GridZen behavior. Treat a request timeout as technical failure: store the HTTP outcome, keep the session pending, and rely on the persisted deadline rather than an in-memory timer. Use bounded retries only where the upstream operation and your workflow permit them, then hand off to review. Never map a timeout, malformed response, missing credentials or provider rejection onto the same state. When recover returns expired, show the user a neutral message and offer a new session through your normal path, or route to an owner. The fixture's error codes are useful contract checks: an event for an unknown session raises BINDING_MISMATCH, and reading an unknown session raises SESSION_NOT_FOUND. Even after approved, the handoff output sets verified false and next_action read_current_evidence_and_policy_before_explicit_decision, because Approved is not unconditional permission.

Limits you should state plainly

The fixture proves local state transitions only. It does not verify real signatures, does not poll any provider, and its grants are not live business permissions. For hosted Didit onboarding, creation, signed callback and authoritative retrieval are evidenced, but a new person passing the full hosted journey remains untested, and end-to-end live customer action remains unverified. Live route availability requires separate confirmation. The anonymous three-scenario HTTP trial is a different artifact from this downloadable example; do not treat one as the other.

Acceptance checklist

Before requesting a sandbox integration, confirm: pending sessions persist with a deadline that survives a restart; a timeout is recorded as technical failure, separate from decision outcome; recover at or after the deadline returns status expired, permission_granted false and provider_polled false; a late or duplicate callback does not change grant_count; a Declined correction revokes the local grant; unknown statuses become unknown, not approved; error codes BINDING_MISMATCH and SESSION_NOT_FOUND are handled; review or authorized fallback has a named owner; and no log line records a 503 as allow or decline. If these pass locally, the next step is an optional saved sandbox request, not live permission.

Run the checked synthetic example

Download and extract https://gridzen.ai/downloads/verification-delivery.zip, enter verification_delivery, then run with Python 3.10+. This local example makes no network calls. Use a fresh database for an independent identity run.

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

Sources and scope

https://gridzen.ai/guides/provider-failures/
https://gridzen.ai/guides/current-capabilities/
Based on the checked source snapshot and local fixture; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.

curl https://gridzen.ai/console/api/quickstart/trial \
  -H 'Content-Type: application/json' \
  -d '{"task": "identity_onboarding", "scenario": "success"}'

This is synthetic integration testing, not identity verification or production authorization. Real payments are disabled.

Create a free sandbox account · Integration guide

Written and tested by the GridZen team with AI assistance.