Testing & Validation
Validate your integration with the self-service tester
Self-Service Integration Tester
Phoenix provides an automated testing service that validates your webhook implementation. It runs 40 tests covering correctness, idempotency, concurrency, and security - the same checks Phoenix uses internally.
Endpoint
https://operators.staging.phoenixbet.io/tester/api/v1/test-run/syncThe tester runs against your staging webhook endpoints only. Make sure your operator's api_url points to your staging environment.
Authentication
Same as all Operator API calls: X-Operator-Id header + X-Signature header. Sign the JSON request body with your private key.
Request
{
"player_id": "test_player_123",
"test_amount_cents": 100
}| Field | Type | Description |
|---|---|---|
player_id | string | A test player with sufficient balance (at least 10x the test amount) |
test_amount_cents | integer | Amount in cents to use for test transactions (default: 1000) |
player_id_b | string (optional) | Second player for cross-player isolation test |
The tester will withdraw and deposit small amounts during testing. All test transactions are cleaned up (rolled back) after the run.
Response
Returns a JSON report with results for each test:
{
"operator_name": "YourPlatform",
"total": 40,
"passed": 38,
"failed": 2,
"skipped": 0,
"results": [
{
"id": "C-01",
"name": "Basic withdraw",
"passed": true,
"checks": [...],
"duration_ms": 245,
"http_calls": 4
}
]
}Streaming Results
For real-time results as each test completes, use the SSE endpoint instead:
POST .../tester/api/v1/test-runThis returns a Server-Sent Events stream with each test result as it finishes.
What the Tester Checks
Correctness (C-01 to C-31)
- Basic withdraw/deposit/rollback with balance verification
- Insufficient balance handling
- Zero amount rejection
- Non-existent player handling
- Idempotency (sequential and concurrent duplicate tx_id)
- Full bet lifecycle flows (win, loss, cancel, mixed)
- Balance precision (cent-level accuracy, no floating-point drift)
- Concurrent request handling
- Batch deposit (if enabled)
Security (S-01 to S-07)
- Requests without signature are rejected
- Requests with invalid signature are rejected
- Tampered request body detected and rejected
- Empty signature rejected
- Signature from wrong key rejected
- No internal details leaked in error responses
- Signature verified against raw body bytes, not re-serialized JSON
Before Running
- Create a dedicated test player with at least 10x the test amount in balance
- Make sure your staging endpoints are reachable
- Verify your webhook endpoints handle the standard request format