Testing & Publishing
Validate your flow with test calls and publish it for live use.
Test mode
Before publishing a flow, switch it to TESTING status to make test calls directly from the editor.
Test calls behave identically to live calls — same AI models, same voice, same latency. The only difference is that test calls are not billed and are clearly marked in your call logs.
Running a test call
- Set the flow status to TESTING
- Click Test Call in the editor toolbar
- Enter a phone number to receive the test call
- The flow executes as it would in production
- Review the call transcript and node execution trace in the test results panel
Validation requirements
A flow must pass validation before it can be published. Requirements include:
| Requirement | Description |
|---|---|
| Main Agent | The flow must have exactly one Main Agent node, and it must be the initial node |
| LLM provider | At least one LLM provider node must be connected |
| TTS provider | At least one TTS provider node must be connected |
| STT provider | At least one STT provider node must be connected |
| Agent prompts | Every agent needs a role message and a task message |
| Unique names | Agent names and function names must be unique within the flow |
| Valid transitions | Every transition target must reference an agent that exists |
If validation fails, the editor highlights which requirements are unmet.
Publishing
Publishing locks the flow and makes it available for assignment to phone numbers.
Status transitions
DRAFT ⇄ TESTING → PUBLISHED → ARCHIVED
↑ |
+-------------------------------+
DRAFT → PUBLISHED (direct publish, skipping test)| Transition | Description |
|---|---|
| Draft → Testing | Enable test calls on this flow |
| Draft → Published | Publish directly, skipping the testing phase |
| Testing → Draft | Revert to draft for further editing |
| Testing → Published | Validation runs. If it passes, the flow is published as an immutable snapshot |
| Published → Archived | Retire the flow. Removes it from active use and unassigns all phone numbers. Can be reactivated to Draft status later. |
| Archived → Draft | Reactivate the flow for editing |
Immutability
A published flow is a snapshot — it cannot be edited. This guarantees that the flow running on your phone numbers is exactly the version you tested and approved.
To make changes to a published flow:
- Open the published version
- Click Create New Version
- A new draft is created with the same configuration
- Edit, test, and publish the new version
- Phone numbers connected to this flow follow the latest version by default and start serving the new version on publish. Phones that were pinned to an earlier version are auto-bumped to the newly published version in the same transaction — no manual reassignment needed.
Comparing versions
Compare two flow versions to see what changed. Open the version history, select two versions, and view a diff of nodes, edges, and configuration changes between them.
Rolling back
Restore a previous version's configuration. Select the target version from the version history and roll back. This auto-publishes the restored configuration as a new version.
Standalone validation
Validate a flow without publishing it. Call the validate endpoint to run the same checks as publishing (including Main Agent, connected LLM/TTS/STT providers, agent prompts, unique names, and transition targets) and receive a list of errors if validation fails. This is useful for CI/CD pipelines or pre-publish checks.