AgentTwinCompare the testing setup
Mockoon can maintain state across requests. The useful distinction is how you define the mock API, run your application and judge its outcome.
| Question | Mockoon | AgentTwin |
|---|---|---|
| Starting point | Configure mock API routes and responses in its application or data files. | Prepare a Node workflow and a world specification with fixtures and assertions. |
| Stateful behavior | Data buckets are shared between routes; CRUD routes can update them. | Supported adapters record operations against the declared service state. |
| Response behavior | Response rules, latency and templating configure the mock API. | Declared supported faults change an operation's behavior during a run. |
| Reset | Restart the mock server or use documented admin API controls to regenerate data buckets. | Fresh run executions start from the declared fixtures; reusable worlds have lifecycle controls. |
| Automation | Mockoon CLI runs mock APIs in automated environments. | AgentTwin CLI runs prepared workflows and writes receipts containing checks and recorded effects. |
See Mockoon's CRUD documentation, data buckets, and CLI overview for these capabilities. AgentTwin's provider contracts define the operations a test world can model.
When to pick each
Pick Mockoon when you need to build and serve an API mock. Its documented workflow lets you shape responses and share data across routes. The CLI makes those mock definitions usable in an automated test setup. Bring the application's test runner and the assertions that decide whether the complete workflow behaved correctly.
Pick AgentTwin when you want to package a supported workflow experiment. Supply the Node entry point, the initial records and the expected effects. AgentTwin runs that prepared bundle against its supported behavior and records the result. A service name found during discovery does not establish adapter coverage.
Keep an existing mock if it already answers your question. A useful evaluation is to take one retry bug and measure the preparation and maintenance each approach requires. We have not run a comparative setup-time or performance benchmark.
A timeout with an observable side effect
Our reference workflow writes a support ticket, then posts a message through the synthetic Slack adapter. The test expects one of each. A timeout after the first write exposes an unsafe retry without involving a real customer account.
npx agenttwin example --out ./agenttwin-example
npx agenttwin run --file ./agenttwin-example/agenttwin.world.json --runtime local --seed 00000000000000000000000000000001 --json
npx agenttwin run --file ./agenttwin-example/agenttwin.world.json --runtime local --fault timeout-after-write --seed 00000000000000000000000000000001 --json
We executed this example on October 24, 2026 with the repository's CLI 0.3.14, through npx --no-install and a local source launcher. Selected fields from the actual faulted JSON output follow; other receipt fields are omitted:
{
"status": "failed",
"runtime": "local",
"fault": {
"service": "crm",
"path": "/tickets",
"type": "timeout-after-write",
"delayMs": 1000,
"triggered": true
}
}
The clean run passed with one ticket and one message. Under the triggered fault, the ticket count was two and the command exited with code 1. We changed only the generated application source to const safe = true, activating its stable request key. Running the same fault again passed with one ticket and one message; the world specification digest was unchanged. This demonstrates the supplied synthetic example, not complete Slack or CRM fidelity.
Supported faults and execution limits
The runtime's fault names are timeout-after-write, blackhole, server-error and duplicate-write. Use a fault supported by the selected operation and inspect whether it actually triggered. Delayed webhooks and expired permissions are not additional built-in fault names in this runtime.
The local runner executes HTTP twins on your computer and retains host filesystem and network access. PostgreSQL and Redis worlds require the configured cloud runtime. Cloud usage is charged to the configured E2B account, and API operators control quotas. AgentTwin subscription pricing is not publicly listed.
The Stripe adapter is a bounded synthetic subset with customer and payment-intent operations. It does not implement refunds, webhooks or subscriptions. Consult supported operations before selecting a payment example.
Frequently asked questions
Is Mockoon limited to static responses?
No. Its documentation describes templates, response rules, data buckets and stateful CRUD routes.
Can Mockoon reset state?
Yes. Its data-bucket documentation describes regeneration through a server restart or admin API controls. Decide when your own tests need that reset.
Can I run Mockoon in CI?
Yes. Mockoon CLI is documented for automated environments, with npm, Docker and GitHub Action options.
Does AgentTwin automatically recreate my APIs?
No. You prepare the workflow and rely on explicitly supported behavior. An unsupported operation makes the test's coverage incomplete.
Do I need cloud credentials for the example?
No. This example runs locally on Node.js 22.12 or newer. Review the generated code because local execution has access to your machine.
Sources and next steps
Competitor documentation reviewed October 24, 2026: Mockoon documentation scope, CRUD routes, data buckets, and Mockoon CLI.
Read the AgentTwin documentation and CLI reference, compare AgentTwin with Pact, or explore Keploy alternatives.