Building the app got fast. Proving the integration still takes days.
Apps from Lovable, Bolt, v0, and Replit now ship real payment and messaging integrations, written by an agent and reviewed by someone who did not write a line of it. FetchSandbox gives those integrations a service twin to run against, so the lifecycle is proven before real money moves.
The short answer
Point your coding agent at a stateful twin of the provider and make it run the whole lifecycle, including the failure branches. A twin keeps state between calls, delivers the same webhook twice on request, and can fail auth in the middle of a flow. Every run returns a receipt you can attach to the pull request, which is the part code review cannot produce on its own.
The generated code is not the risk. The second delivery is.
Generated integrations almost always handle the happy path correctly. The agent read the same docs you would have read, and the first request returns 200. That is exactly why review passes.
What survives review is everything that only happens the second time: the retried webhook, the expired token, the dropped delivery, the event that arrives out of order. None of it is visible in a diff, and none of it is reproducible on demand in staging. So verification becomes days of manual poking, or it becomes production.
Mock, staging, or twin
| Behaviour you need | Where you get it | How |
|---|---|---|
| Returns a shaped response | Mock | Yes |
| Keeps state between calls | Twin | A create can be read back |
| Delivers the same webhook twice | Twin | webhook_retries, same event id |
| Drops a webhook entirely | Twin | flaky_webhooks |
| Fails auth mid-flow | Twin | auth_failure |
| Throttles you at step three | Twin | rate_limited |
| Produces a shareable receipt | Twin | Run trace plus verdict |
Four failures that survive code review
The retry that fires twice
Providers deliver at least once. The generated handler dedupes on the wrong field, or not at all, so a redelivered success event fulfils the order a second time. Scenario: webhook_retries replays the same event id with backoff.
The 401 in the middle
The token was valid at step one and expired by step four. Generated code usually treats the first success as proof the session is good for the whole flow. Scenario: auth_failure.
The webhook that never lands
Nothing errors. The order simply sits in pending forever because there is no reconcile path. Scenario: flaky_webhooks drops a percentage of deliveries.
The valid signature on a stale event
Signature verification passes because it always would. Nobody checked the timestamp, so a replayed event is accepted. Scenario: replayed_old_signed_event.
Let the agent that wrote it run it
FetchSandbox is an MCP server, so Claude, Cursor, or Lovable can drive the twin directly. In Lovable, the connector needs a bearer token from fetchsandbox.com/keys. The useful prompt is not “write the integration” but “run the lifecycle and show me the failure branch.”
“Run the Stripe accept_payment workflow, then re-run it under the webhook_retries scenario. Tell me whether the order was fulfilled once or twice, and give me the receipt URL.”
“Run the Twilio send_sms workflow with auth_failure injected mid-flow. Does my handler retry, or does it drop the message silently?”
The same run is available from the CLI when you want CI to gate on it rather than a person.
The receipt is the reviewable artifact
Every run produces a receipt at a shareable URL containing the requests made in order, the state the twin held, the webhook events delivered, and a verdict. The verdict matters most: a run can return HTTP 200 at every step and still come back unproven, so “the request succeeded” and “the behaviour was correct” stay separate.
That is what turns an unreviewable diff into something a teammate can sign off. Attach the URL to the PR instead of asserting it worked locally.
Payments, messaging, and auth twins
These have curated workflows and failure scenarios rather than spec-generated endpoints alone. AgentMail is covered too, for agent inbox and scoped webhook flows.
Questions people ask
Can I use FetchSandbox from Lovable, not just Cursor?
Yes. Create an API key at fetchsandbox.com/keys. In Lovable connectors, add a custom MCP server at https://fetchsandbox.com/mcp/v1 and choose Bearer token or API key — not None, not OAuth. Chat connectors are personal and are not part of the published app. Then ask the agent to boot a twin and arm a failure such as webhook_retries.
How do I test the Stripe integration my AI app builder generated?
Run the provider's full lifecycle against a stateful twin rather than checking that the endpoint returns 200. Create the payment, capture it, deliver the webhook, then re-deliver the same event id and confirm the order is only fulfilled once. FetchSandbox exposes this over MCP, so the agent that wrote the code can run the flow and hand you a receipt.
Why aren't mocks enough for payment and messaging code?
A mock returns the response you told it to return. It does not retry, it does not deliver the same webhook twice, and it does not expire a token halfway through a flow. Those are the behaviours that break generated integrations, because they only appear on the second delivery.
Isn't this what staging is for?
Staging proves the happy path against real credentials. It will not reliably reproduce a duplicate webhook, a 429 in the middle of a multi-step flow, or a validly signed but stale event. You would have to wait for those to happen. A twin lets you request them on demand.
Does this replace the provider's own sandbox?
No. Use the provider sandbox for final validation against real credentials. A service twin is the fast layer while the integration is being written and reviewed, when you need to force failure branches repeatedly.
I did not write the integration code. How do I review it?
Stop reading the diff for correctness and ask for evidence instead. Require a run receipt showing the retry did not double-charge and the auth failure was handled. A receipt is reviewable even when the code is unfamiliar; a diff written by an agent largely is not.
Which providers have twins today?
Payments, messaging, and auth are the deepest: Stripe, Paddle, Resend, Twilio, Clerk, Descope, and AgentMail all have curated workflows and failure scenarios. The wider catalogue covers 50+ APIs generated from their OpenAPI specs.
Start here
Connect the MCP server once, then make the failure branch a required step before the next integration ships.