Inbound vs Outbound

Overview

When running simulations in Roark, you have two fundamental testing directions based on who initiates the call. This choice affects how your tests execute, what you can test, and how you configure your simulations.

Inbound Testing

In inbound testing, Roark calls your agent to simulate incoming customer calls.

How It Works

You provide your agent’s phone number or endpoint
Roark initiates calls to your agent
The simulated customer (persona) interacts with your agent
Your agent responds as it would to a real incoming call

Characteristics

Immediate execution - Tests run as soon as triggered
Multiple iterations - Can repeat the same test multiple times
High control - Roark controls timing and execution
Synchronous results - Get results immediately after completion

Use Cases

Perfect for testing:

Customer service lines - Support hotlines, help desks
IVR systems - Automated phone menus
Receptionist agents - Virtual assistants answering calls
Emergency response - Crisis hotlines, urgent support
Inbound sales - Agents handling incoming inquiries

Configuration

Direction: Inbound
Agent Endpoint: +1-555-0100 or sip:agent@domain.com
Iterations: 1-100 (configurable)
Concurrency: Up to 50 simultaneous calls

Outbound Testing

In outbound testing, your agent calls Roark to simulate outbound campaigns.

How It Works

Roark provisions a phone number for each test case in your run plan
Your agent can start the call either by exposing an outbound call endpoint that Roark will trigger automatically, or by directly calling the provisioned number shown on the run plan page.
Roark answers as the simulated customer (persona)
Your agent conducts the outbound call scenario

Triggering an outbound call

In an outbound simulation, your agent is responsible for starting the simulated call. This can be done in two ways:

HTTP Endpoint (Suggested)

By setting up an outbound call HTTP request, Roark can automatically start your outbound tests for you - giving you the benefits of scheduling and concurrency control.

Setup an HTTP request on the agent endpoint that will be used in the simulation
Whenever a simulation is started for this agent endpoint, Roark will make the specified HTTP request passing in the provisioned phone number as {{phoneNumberToDial}}.
This HTTP request is expected to trigger your agent to start an outbound call by dialing {{phoneNumberToDial}}.

This automates the workflow of running outbound tests - Roark will handle generating the number and calling your endpoint, and your system simply initiates the call.

Template variables such as {{ phoneNumberToDial }} can be used in the URL, body, and headers.

Provider Examples

Below are minimal example configurations for common voice AI providers. The {{phoneNumberToDial}} template variable will be replaced with the provisioned Roark number at runtime.

VAPI
Retell
ElevenLabs

URL:

POST https://api.vapi.ai/call

Headers:

{
  "Authorization": "Bearer <YOUR_VAPI_API_KEY>",
  "Content-Type": "application/json"
}

Body:

{
  "customer": {
    "number": "{{phoneNumberToDial}}"
  },
  "assistantId": "<YOUR_VAPI_ASSISTANT_ID>",
  "phoneNumberId": "<YOUR_VAPI_PHONE_NUMBER_ID>"
}

See the VAPI API documentation for additional options.

URL:

POST https://api.retellai.com/v2/create-phone-call

Headers:

{
  "Authorization": "Bearer <YOUR_RETELL_API_KEY>",
  "Content-Type": "application/json"
}

Body:

{
  "from_number": "<YOUR_RETELL_PHONE_NUMBER>",
  "to_number": "{{phoneNumberToDial}}",
  "override_agent_id": "<YOUR_RETELL_AGENT_ID>"
}

See the Retell API documentation for additional options like metadata, retell_llm_dynamic_variables, and agent overrides.

URL:

POST https://api.elevenlabs.io/v1/convai/batch-calling/submit

Headers:

{
  "xi-api-key": "<YOUR_ELEVENLABS_API_KEY>",
  "Content-Type": "application/json"
}

Body:

{
  "call_name": "<YOUR_BATCH_CALL_NAME>",
  "agent_id": "<YOUR_ELEVENLABS_AGENT_ID>",
  "recipients": [
    {
      "phone_number": "{{phoneNumberToDial}}"
    }
  ]
}

See the ElevenLabs API documentation for additional options.

Manual Calls

If an HTTP request is not configured, when running a simulation Roark will display the provisioned phone number for each test case in the dashboard. You can then manually trigger your agent to dial that number. Alternatively, you can trigger calls programmatically using our APIs. This is useful when you need full control over when simulations run within your own orchestration logic.

Trigger the simulation run plan

Start a simulation by calling the Run a Simulation Plan endpoint with your run plan ID.

POST /v1/simulation/plan/{planId}/job

This returns a simulationRunPlanJobId for tracking the executed simulation run plan job.

Fetch the simulation run plan job

Retrieve the job details using the Get Simulation Plan Job endpoint.

GET /v1/simulation/plan/job/{jobId}

The response includes a list of individual simulation jobs.

Dial pending jobs

Look for jobs with status: "WAITING_FOR_OUTBOUND_CALL". For each of these, have your agent dial the roarkPhoneNumber provided in the job object to start that simulation.

Repeat for queued jobs

Depending on your run plan configuration, some jobs may be queued while others are in progress. Monitor when each call completes, then repeat steps 2–3 until the Get Simulation Plan Job endpoint returns status: "COMPLETED".

While the programmatic approach offers flexibility, we recommend using HTTP requests instead. Roark will automatically trigger calls at the right time, handling queued simulations and concurrency limits for you.

For both HTTP requests and manual calls, Roark expects the outbound call to be made by the number set in your agent endpoint. Calls made to the provisioned number from numbers other than the one defined in your agent endpoitn will be ignored.

Characteristics

Asynchronous execution - Tests wait for your agent to call
Single iteration - One test per phone number
Agent-controlled timing - Your system decides when to call
Pending state - Test cases remain pending until called

Use Cases

Perfect for testing:

Sales campaigns - Cold calling, lead follow-up
Appointment reminders - Medical, service appointments
Survey calls - Customer satisfaction, market research
Collections - Payment reminders, account management
Notifications - Alert calls, status updates

Configuration

Direction: Outbound
Phone Numbers: Provisioned by Roark
Iterations: 1 (fixed)
Timeout: Configurable (default 24 hours)

Key Differences

Aspect	Inbound	Outbound
Who calls who	Roark → Your Agent	Your Agent → Roark
Execution	Immediate	When agent calls
Iterations	Multiple supported	One per number
Use case	Customer service	Sales/outreach
Timing control	Roark controls	You control
Phone numbers	Use your existing	Roark provisions
Concurrency	High (up to 50)	Limited by numbers
Results	Immediate	After agent calls

Choosing the Right Direction

Choose Inbound When:

Testing customer service scenarios
You need immediate results
Running high-volume tests
Testing response to incoming requests
Validating IVR flows

Choose Outbound When:

Testing sales or marketing campaigns
Your agent initiates contact
Testing dialer integrations
Validating outreach scripts
Testing follow-up workflows

Technical Considerations

Inbound Testing

Ensure your agent can handle concurrent calls
Configure appropriate rate limits
Test your agent’s scaling capabilities
Monitor response times under load

Outbound Testing

Plan for phone number provisioning time
Set appropriate timeouts for pending tests
Configure your dialer to call Roark numbers
Handle failed call attempts gracefully

Best Practices

Start with Inbound

Begin with inbound testing for immediate feedback before moving to outbound

Match Production Patterns

Choose the direction that matches how your agent operates in production

Test Both Directions

If your agent handles both, test both directions for complete coverage

Monitor Phone Number Usage

For outbound, track which numbers have been called to avoid duplicates

Set Realistic Timeouts

Configure appropriate timeouts for outbound tests based on your calling patterns

Next Steps

Create Run Plans

Build test suites with your chosen direction

Configure Personas

Set up customer profiles for testing

Running Simulations

Execute your inbound or outbound tests

View Examples

See scenario examples for both directions

Getting Started

Observability

Metrics

Simulations

Integrations

SDKs & Libraries

Resources

Overview

Inbound Testing

How It Works

Characteristics

Use Cases

Configuration

Outbound Testing

How It Works

Triggering an outbound call

HTTP Endpoint (Suggested)

Provider Examples

Manual Calls

Characteristics

Use Cases

Configuration

Key Differences

Choosing the Right Direction

Choose Inbound When:

Choose Outbound When:

Technical Considerations

Inbound Testing

Outbound Testing

Best Practices

Next Steps

Create Run Plans

Configure Personas

Running Simulations

View Examples

Getting Started

Observability

Metrics

Simulations

Integrations

SDKs & Libraries

Resources

​Overview

​Inbound Testing

​How It Works

​Characteristics

​Use Cases

​Configuration

​Outbound Testing

​How It Works

​Triggering an outbound call

​HTTP Endpoint (Suggested)

​Provider Examples

​Manual Calls

​Characteristics

​Use Cases

​Configuration

​Key Differences

​Choosing the Right Direction

​Choose Inbound When:

​Choose Outbound When:

​Technical Considerations

​Inbound Testing

​Outbound Testing

​Best Practices

​Next Steps

Create Run Plans

Configure Personas

Running Simulations

View Examples

Overview

Inbound Testing

How It Works

Characteristics

Use Cases

Configuration

Outbound Testing

How It Works

Triggering an outbound call

HTTP Endpoint (Suggested)

Provider Examples

Manual Calls

Characteristics

Use Cases

Configuration

Key Differences

Choosing the Right Direction

Choose Inbound When:

Choose Outbound When:

Technical Considerations

Inbound Testing

Outbound Testing

Best Practices

Next Steps