Sandbox Testing

The API Express sandbox mirrors production exactly — same endpoints, same response format, same behaviour — but uses mock data and never charges your account. Build confidently before you go live.

Overview

The sandbox is a full mirror of the production API. Every endpoint, every parameter, every response field works the same way. The only differences are:

• Mock data — Instead of hitting real source databases, responses use curated mock data
• No charges — Sandbox calls don't count against your quota or billing
• Deterministic test values — Specific test inputs trigger specific outcomes (success, failure, edge cases)
• Different base URL — Uses sandbox.api.apiexpress.in instead of the production host

Getting Sandbox Keys

When you sign up for API Express, you automatically get both a sandbox key and a production key. Both are available in your dashboard.

Key prefixes

Generating additional sandbox keys

You can generate multiple sandbox keys — useful for different developers, environments, or test suites. Navigate to Dashboard → API Keys → Generate Sandbox Key.

Sandbox Base URL

The sandbox uses a different host than production. All other path segments stay identical.

Environment configuration

Configure your code to switch between the two with a single environment variable:

// config.js
const BASE_URL = process.env.NODE_ENV === 'production'
  ? 'https://api.apiexpress.in'
  : 'https://sandbox.api.apiexpress.in';

const API_KEY = process.env.NODE_ENV === 'production'
  ? process.env.API_KEY_LIVE
  : process.env.API_KEY_SANDBOX;

export { BASE_URL, API_KEY };

Then use it everywhere:

// Example: fetch weather from correct environment
const response = await fetch(
  `${BASE_URL}/v1/weather?city=Mumbai`,
  { headers: { 'Authorization': `Bearer ${API_KEY}` } }
);

Mock Data

Sandbox responses use curated mock data. The data is realistic and consistent — the same input always returns the same output. This makes it easy to write automated tests.

Response structure is identical

Every field, every type, every nested object — the sandbox response schema is identical to production. Only the values differ.

Example: Weather API in sandbox

{
  "status": "success",
  "city": "Mumbai",
  "temp": 28.5,
  "humidity": 65,
  "condition": "Clear",
  "wind_speed": 12.3,
  "rain_chance": 10,
  "uv_index": 6,
  "updated": "2026-10-05T10:00:00Z"
}

The structure matches production exactly. Weather values are static mock values that don't change.

Example: KYC verification in sandbox

{
  "status": "success",
  "verified": true,
  "name_match": "exact",
  "pan_status": "active",
  "category": "Individual"
}

Test Scenarios

Use specific test inputs to trigger specific outcomes. This lets you test both success paths and error handling.

Test mobile numbers (Recharge API)

Test PAN numbers (KYC API)

Test RC numbers (Vehicle RC API)

Test bank accounts (UPI/Bank Verification API)

Test UPI VPAs (UPI/Bank Verification API)

Test cities (Weather, AQI, Fuel APIs)

Going to Production

When your integration is tested and working in sandbox, switching to production is a one-line change — swap the base URL and the API key.

Pre-launch checklist

• ✅ All API calls work with sandbox keys and return expected data
• ✅ Error handling covers all status codes (400, 401, 403, 404, 422, 429, 5xx)
• ✅ Webhooks verify signatures before processing
• ✅ Retry logic implements exponential backoff
• ✅ Idempotency keys are used for write operations (recharge, verification)
• ✅ Production API keys are stored in environment variables (not source code)
• ✅ Monitoring is set up for error rates and response times
• ✅ Usage alerts configured in the dashboard

Switch to production

# .env (development)
NODE_ENV=development
API_KEY_SANDBOX=sk_test_1a2b3c4d5e6f...
API_KEY_LIVE=

# .env (production)
NODE_ENV=production
API_KEY_SANDBOX=
API_KEY_LIVE=sk_live_1a2b3c4d5e6f...

Deploy the change, verify a small volume of calls succeed, then ramp up traffic. If anything breaks, roll back instantly — the sandbox is always available.

Best Practices

Write automated tests against the sandbox

The sandbox is deterministic — the same input always returns the same output. This makes it ideal for automated testing. Write unit and integration tests that hit the sandbox to verify your integration works end-to-end.

Test error scenarios first

Most developers test the happy path first and handle errors later. Reverse this: trigger every error scenario in the sandbox before writing the success flow. Robust error handling is what separates production-quality code from prototype code.

Use both sandbox keys in CI/CD

Use one sandbox key for local development and another for CI/CD pipelines. This isolates usage between developers and automation, and makes it easy to revoke a specific environment's key without affecting others.

Never ship sandbox keys to production

It's easy to accidentally deploy with a sandbox key. Add a sanity check in your deployment script that fails the build if a sk_test_ key is found in production environment variables.

# deployment-check.sh
if [[ "$NODE_ENV" == "production" ]] && [[ "$API_KEY" == sk_test_* ]]; then
  echo "ERROR: Sandbox key detected in production!"
  exit 1
fi

Keep sandbox and production code paths identical

Never write code like if (env === 'sandbox') { ... } else { ... } — the entire point of a sandbox is to mirror production. The only difference should be the base URL and the API key.

Related Documentation

• Authentication — Understand sandbox vs production keys
• Error Codes — Test error scenarios in sandbox
• Webhooks — Test webhooks against your dev endpoint
• Rate Limits — Sandbox and production rate limits