Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cekura.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
What is Inbound Testing?

If your agent is built to receive calls (a support line, a booking line, an IVR), Cekura tests it by placing the call itself. You select evaluators, hit run, and Cekura dials your agent’s configured number as the simulated caller. Transcripts, metrics, and results land in your dashboard exactly the same way outbound runs do. If instead your agent is built to make calls, see Auto Outbound Calls — the direction of the call decides which guide applies, not the testing framework you use.

​
How It Works

1

Set Inbound on the Agent

In agent settings, set the Inbound flag to ON (inbound: true).
2

Configure the Phone Number

Add the phone number Cekura should dial in Agent Settings. This is the number that reaches your agent. You can override it per run when needed.
3

Run Evaluators

Trigger scenarios from the UI, the API, or your CI pipeline. Cekura places the call to your agent’s configured number and runs the scenario.
4

Review Results

Check transcripts, metric evaluations, and pass/fail status in your dashboard once the run completes.

​
Prerequisites

  • Inbound mode enabled: Agent’s inbound must be set to true
  • Reachable phone number: A number on your stack that routes to the agent under test (your provider’s number, a Twilio BYO number, or a Cekura-issued number)
  • Evaluators ready: Scenarios that define what the simulated caller should say and what the metrics should grade
Inbound testing does not require voice-provider API keys on Cekura’s side — Cekura is the caller, not the agent. Your agent answers the call using its own stack as it would in production.

​
Triggering a Run

Once the agent is configured, any of the standard run-trigger surfaces will place a call:
  • Dashboard — open the scenario(s) and click Run.
  • API — call the standard scenario-run endpoint with the scenario IDs you want to execute.
  • CI/CD — use the GitHub Actions integration to run on push, pull request, or schedule. The action is direction-agnostic; the agent’s inbound flag is what controls who places the call.
The trigger surface only decides when the run fires. The call direction is always determined by the agent’s inbound flag.

​
Overriding the Number Per Run

You can override the destination number on a per-scenario basis without changing the agent’s default. This is useful when the same agent is deployed to multiple numbers (staging vs. production, region-specific lines).
  1. Edit the scenario.
  2. Open the Configuration section.
  3. Set the phone number you want Cekura to dial for this scenario.
Bring-your-own-number setups are documented in Twilio phone numbers and Plivo phone numbers.

​
Inbound vs. Outbound

Agent roleDirection of test callGuide
Receives calls (support, IVR, booking line)Cekura → your agentThis page
Makes calls (lead follow-up, reminders, outreach)Your agent → Cekura’s numberAuto Outbound Calls
The role Cekura plays in testing mirrors the role the caller plays in production: whoever picks up the phone is the agent.

​
Troubleshooting

Verify the phone number on the agent (or scenario override) routes to your agent in production. Place a manual call to the same number — if it doesn’t reach the agent, the issue is upstream of Cekura.
Check that the agent’s transport (SIP trunk, Twilio number, provider webhook) is reachable from the public internet and is configured to answer the test number. Provider-side rate limits and number-blocking rules can silently drop test calls.
The most common cause is inbound: false on the agent. Confirm the flag in Agent Settings. The same agent cannot be tested in both directions in a single run — duplicate the agent if you need both flows.

​
Next Steps