Skip to main content
When your app integrates with services like Stripe, Slack, or Notion, testing locally means either hitting real APIs (risky, rate-limited, costs money) or maintaining hand-written mocks (fragile, always out of date). Arga’s digital twins give you a third option: spin up API-compatible replicas of these services and point your local app at them.

​
How it works

Each twin is a full API emulator that runs on Arga’s infrastructure and is reachable via a public URL. Your app talks to the twin URL instead of api.stripe.com or api.slack.com — no code changes needed beyond swapping environment variables.
Twins maintain realistic state (users, channels, files, payments), support webhooks, and behave like the real service — so you can test end-to-end flows without side effects. Twins start with minimal auth infrastructure and no content; use scenario seeding or API calls to populate the data your tests need.

​
Spin up twins

From your project directory:
The wizard walks you through three steps:
  1. Select twins — pick the services your app uses (Slack, Stripe, Notion, etc.)
  2. Review .env changes — the wizard detects your environment variables and rewrites them to point at twins. Your original .env is backed up to .env.arga-backup.
  3. Wait for provisioning — twins spin up in under a minute
Once ready, start your app normally. All API calls to the selected services now route through twins.

​
Example: testing a Stripe checkout flow

The Stripe twin supports customers, payment intents, subscriptions, checkout sessions, webhooks, and more. Test card numbers trigger the same outcomes (declines, 3D Secure) as Stripe’s own test mode.

​
Example: testing Slack messaging workflows

The Slack twin starts with a workspace and users but no channels — create them through scenario seeding or the conversations.create API. It also supports OAuth flows if your app has an “Add to Slack” install step.

​
Managing your session

Twin sessions last 10 minutes by default. Use these commands from your project directory: Session state is tracked in .arga-session.json in your project root. Add it to your .gitignore. From that same project directory, arga runs logs can read .arga-session.json automatically, so you can inspect the current logs snapshot for the active run without passing a run ID. Add --errors-only to focus on failed worker logs and warning/error runtime logs.

​
Restoring your original environment

Or just tear down the session — but remember to restore your .env manually since teardown doesn’t revert it.

​
Available twins

UI twins have an interactive dashboard where you can see and manipulate state in the browser. Backend-only twins respond to API calls but don’t have a visual interface. See the twin reference for per-twin support, limitations, and MCP tool coverage. See the twins quickstart for quickstart state and environment variables.

​
Tips

After spinning up twins and starting your app, run an Arga validation against your local deployment (exposed via a tunnel like ngrok or Cloudflare Tunnel) to get automated browser-level testing with twins backing every integration.
You can provision twins in a CI pipeline by calling the API directly or running npx arga-wizard non-interactively. Set ARGA_API_KEY as a secret and the wizard will skip the key prompt.
Add these to your .gitignore: