Go-Live Checklist

Complete every item before switching from sandbox to production. This is your pre-flight checklist.

Production readiness

API integration

• [ ] Webhook endpoint deployed and accepting FAST payloads over HTTPS
• [ ] HMAC-SHA256 signature verification over the raw body (X-Webhook-Signature), with a length-checked constant-time comparison
• [ ] Adapter mapping configured and tested via the operator backoffice
• [ ] All webhook event types handled (even if some are no-ops, return 200)
• [ ] Error handling for all HTTP status codes (400, 401, 404, 409, 422, 429, 500, 503)
• [ ] correlationId logged from every FAST response for debugging
• [ ] Rate limiting awareness: your integration stays within endpoint limits
• [ ] Production API key and widget key stored securely in environment variables (not in client-side code, except pk_...)
• [ ] Staging test flow completed end-to-end (purchase, bet, settle, complete, withdraw)
• [ ] Test rulesets and tiers (such as the Quickstart tier) deleted on the production tenant: Clone to Production copies every ruleset and tier from staging
• [ ] Retry logic with exponential backoff for 429 and 500 responses

User-facing UI

• [ ] Challenge tier selection and purchase flow
• [ ] Challenge progress display (balance, target, days remaining, active days)
• [ ] Cooldown state reflected in betting UI (block bets when cooldownUntil is set)
• [ ] Funded account balance and profit display
• [ ] Withdrawal flow driven by the payout state (payout.canRequest, payout.reasons, gross amount with the share beside it)
• [ ] First-payout deadline shown to funded users (firstPayoutDeadlineAt)
• [ ] Rejection reason codes mapped to user-friendly messages
• [ ] Rules disclosure shown before purchase (use GET /v1/challenge-tiers/:id/terms)

Operational

• [ ] Reconciliation process scheduled (daily recommended)
• [ ] Monitoring for webhook delivery failures
• [ ] Alerting on elevated error rates from FAST API calls
• [ ] Runbook for handling FAST maintenance mode (503 responses)
• [ ] On-call contact designated for first 48 hours post-launch

Sandbox test scenarios

Verify each scenario end-to-end before go-live:

Scenario	What to verify
Challenge purchase	201 response, challenge.activated webhook received
Duplicate purchase	409 active_challenge_exists response
Bet validation (accepted)	accepted status returned, bet confirmed in your system
Bet validation (rejected)	rejected status with reason codes, bet blocked in your UI
Challenge pass	challenge.passed webhook, progress type: challenge_passed with continue/refund choices
Continue after pass	challenge.completed + funded_account.activated webhooks
Refund after pass	challenge.stake_refunded + challenge.bonus_voided webhooks, own stake refunded in your system
Challenge failure (drawdown)	challenge.failed webhook; re-purchase returns 429 purchase_cooldown until midnight UTC, then succeeds
Challenge failure (expired)	challenge.failed webhook after duration
Funded account withdrawal	Sent with X-Idempotency-Key; totalPayout paid (includes own stake on the first payout); funded_account.payout webhook
Funded account revocation	funded_account.revoked webhook, access removed
Cooldown trigger and lift	cooldown.triggered webhook, bets blocked, cooldown.lifted webhook
Reconciliation	Bet counts and IDs match between your system and FAST
Rate limiting	Your system handles 429 gracefully with backoff

How to run sandbox tests

# 1. Purchase a challenge
curl -X POST https://api.fundedfast.eu/v1/challenges/purchase \
  -H "X-API-Key: YOUR_STAGING_KEY" \
  -H "Content-Type: application/json" \
  -d '{"userId": "test-user-1", "challengeTierId": "YOUR_TIER_ID"}'

# 2. Place winning bets until balance exceeds target
curl -X POST https://api.fundedfast.eu/v1/bets \
  -H "X-API-Key: YOUR_STAGING_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "userId": "test-user-1",
    "externalBetId": "bet-001",
    "stakeAmount": 10.00,
    "odds": 3.0,
    "status": "settled-won",
    "settlementAmount": 30.00,
    "isCashOut": false
  }'

# 3. Reset when done
curl -X POST https://api.fundedfast.eu/v1/sandbox/reset/test-user-1 \
  -H "X-API-Key: YOUR_STAGING_KEY"

Monitoring setup

Metrics to track from day one

Metric	Alert threshold	Why
FAST API error rate (5xx)	> 1% of requests	Backend issues
FAST API latency (p95)	> 2000ms	Performance degradation
Webhook delivery failure rate	> 5% over 1 hour	Webhook endpoint issues
429 responses	Any sustained occurrence	Rate limit misconfiguration
Challenge purchase success rate	< 95%	Payment or integration issues
Reconciliation mismatches	Any	Data integrity problem

Logging requirements

Log these fields from every FAST API interaction:

{
  "timestamp": "2026-06-05T14:30:00Z",
  "method": "POST",
  "endpoint": "/v1/bets/validate",
  "statusCode": 200,
  "correlationId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "durationMs": 45,
  "userId": "player-42"
}

Always include correlationId in your logs. FAST support requires it for troubleshooting.

Health check integration

Add FAST health to your monitoring:

# Returns component-level status
curl https://api.fundedfast.eu/health

{
  "status": "ok",
  "components": {
    "database": "ok (12ms)",
    "queue": "ok"
  }
}

Monitor this endpoint every 60 seconds. If it returns non-200, FAST may be in maintenance or experiencing issues. Your sportsbook should continue operating normally and queue events for later delivery.

Rollback plan

If something goes wrong after switching to production:

Immediate rollback (< 5 minutes)

1. Disable FAST challenge features in your UI (feature flag)
2. Your sportsbook continues operating without FAST challenges
3. Users see challenges as "temporarily unavailable"
4. No data is lost. Pending bets can be reconciled later.

Partial rollback

If only webhooks are failing:

1. Check webhook delivery log in the operator backoffice
2. Fix your webhook endpoint
3. Retry failed webhooks from the backoffice (FAST stores all payloads)

Data reconciliation after rollback

After resolving the issue and switching back to production:

# Check for any missed bet events
curl -H "X-API-Key: YOUR_API_KEY" \
  "https://api.fundedfast.eu/v1/reconciliation/player-42?from=2026-06-05&to=2026-06-06"

Compare the returned bet IDs with your records. Backfill any missing events via POST /v1/bets.

Switching to production

1. Replace the staging API key with the production API key in your environment variables
2. Replace the staging widget key with the production widget key in your frontend
3. Update the webhook secret to the production webhook secret
4. Verify the first production challenge purchase succeeds
5. Monitor webhook deliveries in the operator backoffice for the first 24 hours

# Verify production connection
curl -H "X-API-Key: YOUR_PRODUCTION_KEY" \
  https://api.fundedfast.eu/v1/challenge-tiers

First-day monitoring tips

1. Watch the first 10 purchases. Confirm each triggers a challenge.activated webhook.
2. Verify bet validation latency. p95 should be under 200ms for /bets/validate.
3. Check webhook delivery. All webhooks should show 200 responses in the backoffice log.
4. Monitor for 409s. A sudden spike in active_challenge_exists errors may indicate a UI bug allowing double-purchase attempts.
5. Review reconciliation. Run a reconciliation check after the first hour of live traffic.
6. Keep the FAST support channel open. Email support@fundedfast.eu or call +385 99 371 341 for priority assistance during your first 48 hours.

Post-launch checklist (first week)

• [ ] Daily reconciliation running and clean
• [ ] First challenge completion processed correctly
• [ ] First withdrawal processed correctly
• [ ] No sustained webhook delivery failures
• [ ] Error rate below 0.5%
• [ ] User-facing messages are clear (no raw error codes shown)
• [ ] Support team briefed on FAST-related user questions

Support

• API documentation: https://docs.fundedfast.eu/api/endpoints
• Email: support@fundedfast.eu
• Phone: +385 99 371 341
• Always include the correlationId when reporting issues