Environments

VelaFlows provides separate environments so you can develop and test integrations without affecting production data.

Live Environment

The live environment is your production workspace. All real conversations, leads, and customer data live here.

When to Use

• Production integrations
• Live customer-facing applications
• Analytics and reporting

Test Environment

The test environment provides a sandbox for developing and testing integrations without risking production data.

When to Use

• Building new integrations
• Testing webhook handlers
• Debugging API calls
• CI/CD test suites

Identifying Your Environment

You can tell which environment you’re using by the token prefix:

# Live token
Authorization: Bearer sk_live_a1b2c3d4e5f6g7h8...
 
# Test token
Authorization: Bearer sk_test_x9y8z7w6v5u4t3s2...

Switching Environments

To switch environments, simply use a different API token. The base URL is the same for both environments — the token determines which environment your request targets.

// Development / testing
const token = process.env.VELAFLOWS_TEST_TOKEN  // sk_test_...
 
// Production
const token = process.env.VELAFLOWS_LIVE_TOKEN  // sk_live_...

Environment Variables Pattern

We recommend using environment variables to manage tokens across environments:

# .env.development
VELAFLOWS_API_TOKEN=sk_test_your_test_token_here
VELAFLOWS_WORKSPACE_ID=64f1a2b3c4d5e6f7a8b9c0d1
 
# .env.production
VELAFLOWS_API_TOKEN=sk_live_your_live_token_here
VELAFLOWS_WORKSPACE_ID=64f1a2b3c4d5e6f7a8b9c0d1

Your application code stays the same — only the token changes:

const response = await fetch(
  'https://api.velaflows.com/api/v1/inbox/conversations',
  {
    headers: {
      'Authorization': `Bearer ${process.env.VELAFLOWS_API_TOKEN}`,
      'x-workspace-id': process.env.VELAFLOWS_WORKSPACE_ID,
    },
  }
)

Environment Parity

Both environments use the same API endpoints, request formats, and response structures. Code that works in the test environment will work identically in production. The only differences are:

• Data isolation — Test and live environments have completely separate data
• Channel behavior — Test environment simulates channel messaging instead of sending real messages
• Rate limits — Test environment has the same rate limits as production

Best Practices

1. Always develop against the test environment first. Switch to live tokens only when your integration is ready for production.

2. Use separate tokens per environment. Never use a live token for testing or a test token in production code.

3. Keep environment config external. Use environment variables or a secrets manager — never hardcode tokens in source code.

4. Test error handling in sandbox. The test environment lets you safely trigger edge cases (rate limits, validation errors) without affecting real data.