Sandbox Testing

The sandbox environment lets you test your integration end-to-end without enrolling real customers or processing real transactions. Use sandbox API keys and test fixtures to get deterministic, predictable results.

Sandbox API keys

Any API key prefixed with test_ routes to the sandbox environment automatically. You receive a sandbox key when you sign up.

# Sandbox — no real signal detection
Authorization: Bearer test_sk_abc123...

# Production — real exploitation monitoring
Authorization: Bearer live_sk_abc123...

Test fixtures

Use specific customer_name patterns when creating profiles to get deterministic results:

Customer Name Pattern	Behavior	Use case
Test Normal *	Profile stays in NORMAL tier, no signals	Happy path testing
Test Draining *	Generates GRADUAL_DRAINING signals on transaction events	Draining detection testing
Test Critical *	Generates CRITICAL-severity signals, tier jumps to CRITICAL	Critical alert flow testing
Test NewRel *	Generates NEW_RELATIONSHIP signals on beneficiary events	New relationship testing
Test POA *	Generates POA_ACCESS_ANOMALY signals	POA abuse testing
Test Cognitive *	Generates COGNITIVE_DECLINE signals on session events	Cognitive decline testing
Test Batch *	Profile is included in batch scan results	Batch operation testing

Example

# This profile will generate draining signals when transaction events are sent
curl -X POST https://api.korastratum.com/sentinel/api/v1/elder/profiles \
  -H "Authorization: Bearer test_sk_abc123" \
  -H "X-Tenant-ID: $SENTINEL_TENANT_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "customer_id": "550e8400-e29b-41d4-a716-446655440000",
    "customer_name": "Test Draining Margaret",
    "date_of_birth": "1945-03-15T00:00:00Z",
    "enrollment_reason": "AGE_THRESHOLD"
  }'

Sandbox behavior

In sandbox mode:

• Profile creation — Profiles are created with a pre-built behavioral baseline (no waiting for the baseline period).
• Event processing — Events are evaluated against fixture baselines and return deterministic signals based on the customer name pattern.
• Signal detection — Signals are generated with fixture confidence scores and severity levels.
• ERS calculation — The ERS is calculated using the same algorithm as production, but against fixture data.
• Webhooks — Delivered normally to your configured endpoint with the same payload format as production.
• Batch operations — Execute instantly and return fixture results.
• Dashboard — Returns fixture aggregated data.

Fixture responses

Normal profile (Test Normal *)

Transaction events return no signals:

{
  "processed": true,
  "enrolled": true,
  "signals": 0,
  "ers_before": 5.0,
  "ers_after": 5.0,
  "tier_changed": false,
  "new_tier": ""
}

Draining profile (Test Draining *)

Transaction events generate draining signals:

{
  "processed": true,
  "enrolled": true,
  "signals": 2,
  "ers_before": 25.0,
  "ers_after": 48.5,
  "tier_changed": true,
  "new_tier": "ELEVATED"
}

Critical profile (Test Critical *)

Any event generates critical signals:

{
  "processed": true,
  "enrolled": true,
  "signals": 3,
  "ers_before": 65.0,
  "ers_after": 88.0,
  "tier_changed": true,
  "new_tier": "CRITICAL"
}

Testing webhooks locally

Use a tunneling service to receive webhooks on your local machine:

# Using ngrok
ngrok http 3000

# Configure your webhook URL in the dashboard, then send a test event
curl -X POST https://api.korastratum.com/sentinel/api/v1/elder/events/transaction \
  -H "Authorization: Bearer test_sk_abc123" \
  -H "X-Tenant-ID: $SENTINEL_TENANT_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "event_type": "transaction.completed",
    "customer_id": "550e8400-e29b-41d4-a716-446655440000",
    "timestamp": "2026-04-07T14:30:00Z",
    "source": "CBA",
    "data": {
      "transaction_id": "770e8400-e29b-41d4-a716-446655440002",
      "transaction_type": "transfer",
      "amount": 500000.00,
      "currency": "NGN",
      "channel": "mobile"
    }
  }'

Sandbox limitations

• Sandbox profiles and signals do not count toward your monthly quota
• Rate limits are the same as production (per your tier)
• Sandbox data is isolated from production — you cannot access sandbox profiles with a production key
• Batch operations in sandbox complete synchronously rather than running in background workers