Documentation

Test mode

Integrate and test your application with predictable responses, zero provider calls, and no quota consumption.

What is test mode?

Test mode allows you to validate your ModelRiver integration without making actual AI provider calls or consuming your request quota. It returns the sample data from your structured output configuration, giving you predictable, repeatable responses for development and testing.

How it works

  1. When creating or editing a workflow, switch the mode toggle from Production to Testing.
  2. In test mode, you must select a Structured Output that contains sample data.
  3. Optionally configure a Response Delay (in milliseconds) to simulate API latency.
  4. When you make API requests to a workflow in test mode:
    • The sample data from the structured output is returned immediately (after any configured delay)
    • No AI providers are called
    • Requests are still logged, so you can review them in Request Logs with the Test source filter
    • Test requests are not counted as billable requests or against your request quota, and spending limits are not applied
    • The response uses the same envelope (data, customer_data, meta) as a live request
    • Async requests still deliver webhooks and wait for backend callbacks, so you can test the full flow

Use cases

Use caseBenefit
Integration testingTest your application's AI integration without consuming API credits
Development environmentsDevelop and debug with predictable responses
CI/CD pipelinesRun automated tests against your API without external dependencies
Demo environmentsShowcase functionality without incurring costs or needing API keys
Load testingTest throughput without hitting provider rate limits. ModelRiver's own rate limits still apply

Response format

Test mode responses include:

  • The sample data from your structured output
  • Cached fields (if configured) echoed from your request
  • Metadata indicating test_mode: true and provider: "Testing"
  • Standard token usage fields (set to 0)

Example response

JSON
1{
2 "message": "success",
3 "status": "success",
4 "data": {
5 "summary": "Sample summary text",
6 "sentiment": "positive",
7 "category": "support"
8 },
9 "customer_data": {
10 "user_id": "usr_test123"
11 },
12 "meta": {
13 "http_status": 200,
14 "workflow": "support_summarizer",
15 "provider": "Testing",
16 "model": "test-mode",
17 "used_provider": "Testing",
18 "used_model": "test-mode",
19 "test_mode": true,
20 "usage": {
21 "prompt_tokens": 0,
22 "completion_tokens": 0,
23 "total_tokens": 0,
24 "cache_read_tokens": 0,
25 "cache_write_tokens": 0,
26 "cache_write_1h_tokens": 0,
27 "reasoning_tokens": 0
28 },
29 "duration_ms": 150,
30 "structured_output": true,
31 "customer_fields": ["user_id"]
32 }
33}

Best practices

  • Always define sample data that matches your schema structure
  • Use realistic sample data to better simulate production behavior
  • Configure response delays to match expected AI provider latency (typically 500-3000ms)
  • Switch workflows back to Production mode before deploying to production environments
  • Use test mode in CI/CD to validate end-to-end request handling without flaky provider dependencies

Next steps