Skip to main content
Twinbay gives every test run its own copy of the third-party APIs your code calls. You describe the state you need in plain language, Twinbay hands back a private hostname and a provider-shaped API key, and the vendor’s own SDK talks to it without a code change beyond the base URL. A twin is not a schema-generated mock. Each one is written by hand against a provider’s behavior: its state machines, pagination, idempotency, authentication and error envelopes. CI validates every twin by running the provider’s official SDK against it.

​
What you get

State you cannot get from a test mode

Hard bounces, declined sends, revoked keys, half-finished workflows. Ask for it in one sentence.

Isolation per run

Every sandbox has its own hostname, records, credentials and request log. Run CI jobs in parallel without sharing state.

Provisioned on demand

Ask for a sandbox and Twinbay builds it: a container per twin, seeded from your scenario, serving within a couple of minutes. Stop it when the suite ends.

A record of what your agent did

Read back every request: method, path, body, status and latency.

​
Where to go next

Quickstart

From an API key to a passing SDK call against a seeded sandbox.

Concepts

Twins, sandboxes, scenarios, credentials, records and time.

CLI

Provision and inspect sandboxes from a shell or a CI job.

MCP server

Give a coding agent the same operations as tools.
Twinbay is free for academic researchers. Sign up in the console with an email address.