Testing Routes
Use KnoxCall’s built-in route tester to validate your configuration before sending real traffic.What is the Route Tester?
The Route Tester is a built-in tool that lets you:- ✅ Test route configuration without writing code
- ✅ See exactly what headers/body are sent to your backend
- ✅ Verify secrets are injected correctly
- ✅ Test different HTTP methods
- ✅ Debug issues before going live
- ✅ No need for Postman or curl
Access the Route Tester
Option 1: From Route List
- Navigate to Routes
- Find your route
- Click the Test button (🧪 icon)
Option 2: From Route Details
- Navigate to Routes
- Click your route to open details
- Click Test Route tab
- Or click Test button in header
Using the Route Tester
Step 1: Select HTTP Method
Choose the method to test:- GET
- POST
- PUT
- DELETE
- PATCH
- OPTIONS
- HEAD
Step 2: Enter Path
Specify the URL path (appended to target base URL): Example: Target Base URL:https://api.example.com
Path: /users/123
Result: https://api.example.com/users/123
Tips:
- Include leading slash:
/api/users✅ - No leading slash:
api/users⚠️ (works but inconsistent) - Can include query params:
/users?status=active
Step 3: Add Query Parameters (Optional)
Add query parameters that will be:- Sent to backend
- Available in templates as
{{vars.param_name}}
| Key | Value |
|---|---|
| filter | active |
| sort | name |
| limit | 10 |
/users?filter=active&sort=name&limit=10
Step 4: Add Request Headers (Optional)
Add custom headers to include in the request: Example:| Header | Value |
|---|---|
| Content-Type | application/json |
| X-Custom-Header | test-value |
Step 5: Add Request Body (Optional)
For POST/PUT/PATCH requests, provide request body: JSON:Step 6: Select Environment (Optional)
Choose which environment to test:- production (default)
- staging
- development
- Custom environments
Step 7: Click “Send Test Request”
KnoxCall will:- Apply route configuration
- Inject secrets (if any)
- Apply environment overrides (if any)
- Apply method-specific config (if any)
- Send request to backend
- Return response
Understanding Test Results
Request Details Section
Shows exactly what was sent to your backend: Request URL:Authorizationheader was injected from route config- Secret was decrypted and value inserted
- Custom headers are included
api_keywas injected from body template- Secret was decrypted
Response Details Section
Shows what your backend returned: Status Code:Config Applied Section
Shows which configuration was used: Environment:Test mode bypasses some security checks:
- Rate limiting is not enforced
- Client IP authorization is skipped
- Signatures are not required
Example Test Scenarios
Scenario 1: Test Secret Injection
Goal: Verify Stripe API key is injected correctly Setup:- Select method: POST
- Path:
/charges - Body:
- Send request
- Request headers show:
Authorization: Bearer sk_live_...(actual key, not template) - Response from Stripe API (charge created)
- No errors about authentication
Scenario 2: Test Method-Specific Config
Goal: Verify POST uses different headers than GET Test GET:- Method: GET
- Path:
/users - Send request
- Check: Authorization header uses
read_key
- Method: POST
- Path:
/users - Body:
{"name": "Test"} - Send request
- Check: Authorization header uses
write_key
Scenario 3: Test Environment Override
Goal: Verify staging environment uses staging URL Setup:- Method: GET
- Path:
/health - Environment: staging
- Send request
- Request URL shows staging URL:
https://staging-api.example.com/health - Not production URL
Scenario 4: Test Query Param Variables
Goal: Verify{{vars.filter}} is replaced correctly
Setup:
- Method: GET
- Path:
/users - Query params:
filter=active
- Send request
- Request headers show:
X-Filter: active(variable replaced) - Not:
X-Filter: {{vars.filter}}(literal template)
Scenario 5: Test Error Handling
Goal: See how backend handles invalid data Setup:- Method: POST
- Path:
/users - Body:
- Send request
- Status code: 400 Bad Request
- Response body shows validation error
- Error message is clear
Common Test Cases
✅ Before Going Live Checklist
Test these scenarios before sending real traffic:-
GET request works
- Returns expected data
- Correct headers injected
- Secrets work
-
POST request works
- Creates resource successfully
- Body template works
- Secrets injected correctly
-
PUT/PATCH request works
- Updates resource
- Idempotency works (if applicable)
-
DELETE request works
- Deletes resource
- Correct permissions
-
Test each environment
- Production URL
- Staging URL
- Development URL
-
Test method configs
- Each method uses correct config
- Secrets differ per method
-
Test error cases
- Invalid data returns 400
- Missing auth returns 401
- Not found returns 404
-
Test with real data
- Not just test values
- Actual production-like payloads
Troubleshooting with Route Tester
Issue: “Connection refused”
Possible causes:- Target URL is wrong
- Backend server is down
- Firewall blocking KnoxCall IPs
- Check target URL in route config
- Verify backend is running:
curl https://your-backend.com/health - Check backend firewall allows KnoxCall IPs
Issue: “401 Unauthorized”
Possible causes:- Secret not injected
- Wrong secret value
- Secret expired
- Check “Request Headers” section
- Verify
Authorizationheader present - Check secret value is correct (not template literal)
- Test secret directly with backend
Issue: Template Not Replaced
Symptoms: Backend receives{{secret:api_key}} literal
Causes:
- Secret doesn’t exist
- Typo in secret name
- Wrong template syntax
- Check “Secrets Injected” section
- Verify secret exists: Secrets page
- Check spelling:
{{secret:api_key}}not{{api_key}}
Issue: “502 Bad Gateway”
Possible causes:- Backend took too long (timeout)
- Backend returned invalid response
- Backend crashed
- Check response time (>30 seconds?)
- Check backend logs for errors
- Test backend directly:
curl https://your-backend.com/endpoint
Issue: Wrong Environment Used
Symptoms: Request went to production instead of staging Debug:- Check environment dropdown selection
- Verify environment override exists
- Check “Config Applied” section shows correct environment
Advanced Testing
Test with cURL Export
Copy test as cURL command to run in terminal:- Configure test in UI
- Click Export as cURL
- Copy command
- Run in terminal:
- Automated testing
- CI/CD pipelines
- Sharing with team
Test with Postman Import
Export test as Postman collection:- Configure test
- Click Export as Postman
- Import in Postman
- Run collection
Test from Logs
Replay a real request from logs:- Navigate to Logs
- Find a request
- Click Replay in Tester
- Tester pre-fills with request details
- Modify and re-send
Best Practices
1. Test Before Deploy
Always test routes before sending production traffic.2. Test All Methods
Don’t just test GET - test POST, PUT, DELETE too.3. Test All Environments
Verify dev, staging, prod all work.4. Test Error Cases
Don’t only test happy path - test failures too.5. Save Test Cases
Document test cases in route description or wiki.6. Test After Changes
Re-test after changing:- Route config
- Secrets
- Environment overrides
- Backend URL
7. Use Real Data
Test with actual production-like data, not just{"test": "data"}.
8. Check Response Times
Monitor how long requests take. Optimize if >1 second.Limitations
Rate Limiting Bypassed
Test mode doesn’t enforce rate limits. Don’t use for load testing.IP Authorization Skipped
Test requests don’t check client IP whitelist.Signatures Not Required
Test mode doesn’t require HMAC signatures.Real Backend Impact
Test requests actually hit your backend. They’re not simulated.Related Features
- Method Configs: Test different configs per HTTP method
- Environments: Test staging before production
- Secrets: Verify secrets inject correctly
- Logs: View historical requests and replay them
Next Steps
Method Configs
Test method-specific configurations
Environments
Test different environments
API Logs
View real request logs
Secrets
Verify secret injection
📊 Statistics
- Level: beginner
- Time: 5 minutes
🏷️ Tags
testing, debugging, routes, tools