Staging overview

Staging exists to validate integration behavior before production with same docs, same paths, same request and response shapes.

Single source of truth

• operator API paths stay same
• wallet adapter paths stay same
• webhook payloads stay same
• dashboard concepts stay same

Only deployment environment differs.

Do not maintain separate staging implementation docs.

What to validate in staging

• launch flow works end to end
• user can view markets
• buy flow works
• sell or redemption flow works
• webhook receiver verifies signature
• webhook retries behave as expected
• duplicate idempotency is safe
• failure and unknown wallet states are visible to operator

Evidence to collect

• API request and response samples
• wallet adapter logs keyed by idempotency_key
• webhook receiver logs keyed by event_id
• operator dashboard screenshots for failed or replayed deliveries
• timestamps in UTC for each drill

Required drill order

1. seed or prepare test user
2. validate launch
3. validate happy-path trade
4. validate payout or redemption
5. validate wallet failure drills
6. validate webhook retry and replay
7. review dashboard evidence

Related pages

• simulator tools: /docs/testing-and-staging/simulator
• webhook drills: /docs/testing-and-staging/webhook-drills
• wallet failures: /docs/testing-and-staging/wallet-failure-drills