Sandbox Overview
The Praevis sandbox is a production-identical testing environment. It uses the same auction engine, the same APIs, and the same dashboard — but no real money changes hands and all data is fully isolated from production.
Supply sources (Publishers) test against synthetic bidders. Demand sources (DSPs) test by sending real bid responses into synthetic auctions. Platform partners test the full flow end-to-end.
Use it to validate your integration before going live.
What the sandbox is
| Sandbox | Production | |
|---|---|---|
| Auction engine | Identical | Identical |
| API endpoints | Identical | Identical |
| Dashboard | Same, sandbox tab | Same, live tab |
| Demand | Synthetic test bidders + demand sources under test | Real demand sources only |
| Revenue | Display only — not real | Real payouts |
| Data isolation | Separate Redis namespace (sandbox:*) | Live data |
| Reset | Flush anytime via API | Never flush |
| Cost | Free | Real billing |
How data isolation works
All sandbox data is stored under a separate Redis key namespace: sandbox:partner:*, sandbox:pub:*, sandbox:dsp:*. There is zero overlap with production keys.
PostgreSQL auction logs from sandbox are flagged with sandbox = true and excluded from billing calculations, invoices, and aggregated reporting.
A supply source in sandbox mode: receives synthetic bid requests, shows metrics in the sandbox dashboard tab, accrues no real revenue.
A supply source in live mode: receives real bid requests, shows metrics in the live dashboard tab, accrues real revenue.
A supply source can only be in one mode at a time. To test a new supply source before going live, create it in sandbox mode first, validate, then switch to live.
Synthetic demand — what it looks like
The sandbox includes pre-configured synthetic DSPs that generate realistic bid patterns:
| Synthetic DSP | Behaviour |
|---|---|
| HighBidder | Always bids above floor; wins most auctions. Tests that your creative pipeline and impression tracking work. |
| LowBidder | Always bids below floor; never wins. Tests empty response handling. |
| RandomBidder | Bids at random CPMs around the floor. Tests mixed fill rate. |
| TimeoutDSP | Never responds in time. Tests circuit breaker and timeout handling on your end. |
Fill rate in sandbox is intentionally higher than production (~70–80%) to make testing easier.
What to test in sandbox
- ✓ VAST tag parses and ad plays correctly
- ✓ RTB bid request arrives at your bidder in the expected format
- ✓ Impression tracking fires after creative plays
- ✓ Revenue appears in the dashboard after ~60 seconds
- ✓ Empty VAST handled gracefully (passback fires, no error)
- ✓ Circuit breaker behaviour when TimeoutDSP is active
- ✓ Delegate strategy conditions match expected auction parameters
- ✓ Daily budget pacing works for Delegate campaigns
Resetting sandbox data
POST /api/sandbox/reset
X-API-Key: {YOUR_KEY}Flushes all sandbox metrics and auction logs for your partner account. Use before a clean validation run. Does not affect production data.
Preview mode
Draft documentation pages (status: draft) are hidden in production but visible in sandbox using:
https://docs.praevis.com/any-page?preview=trueThis is a static token — no login required. Share with internal reviewers before publishing.