Hi, I'm the author. Quick tour before the comments do it for me.
StuntAPI, `stunt` for CLI friends, runs local, stateful stand-ins for the public APIs your code talks to. `brew install --cask stuntapi/tap/stunt`, then `stunt demo` — you get a Stripe-style sim on a local port, and the curl it prints actually means it:
create a charge, list it back (the charge is there — state persists across requests and restarts), capture it, and watch the signed webhook fire at a local sink. All synthetic, all offline, no Stripe account.
Why I built it: I've spent twenty-odd years integrating other people's APIs — commodities trading and market data in London, fintech, payments, blockchain RPC infra — and the test story never got better. Sandbox accounts, live secrets in CI, rate limits, flaky suites because the mock didn't behave like the real thing. WireMock/Prism/MSW are great at static and schema-shaped mocks; what I always wanted was a runnable stand-in — create, list, mutate, webhooks, auth expiry, cursor pagination, state machines — without writing it all myself. So: 95 adapters (Stripe, Twilio, GitHub, S3, Salesforce, ...), each one YAML + sandboxed Starlark handlers + synthetic fixtures.
The part I'd genuinely like holes poked in: adapters run in a Starlark VM with no host I/O or network — that's the property that makes it safe to `stunt catalog add` a stranger's adapter, the way you'd install an npm package. State lives in engine primitives (SQLite collections, KV, blob store, HMAC tokens, webhook emitter with real provider signature schemes), and everything is deterministic — injectable clock, seeded RNG.
Yes, this works great in tests of course.
To keep the adapters honest, CI drives the real provider SDKs against them: stripe-go, aws-sdk-go-v2 (real SigV4), go-github, twilio-go, go-shopify, and the Node trio (stripe-node, octokit, twilio-node) through the actual binary.
And this is just the beginning, if there's traction, we'll see more and more of these. I'll just keep adding the ones I use personally for now.
That harness caught real bugs: Stripe money fields coming back as JSON strings (typed SDKs just reject the response), GitHub pagination Link headers pointing at production — octokit followed them straight to the real api.github.com.
Honest limits: adapters are unofficial and fidelity-ranked, not API-complete; I'd rather nail the flows real integrations actually exercise than checkbox every endpoint. Windows is currently a script install rather than the default winget source. And if you integrate an API that's missing, `stunt adapter import openapi|har|proto` scaffolds one — PRs welcome. Docs @ https://stuntapi.com
What should adapter #96 be? I'm Alessandro BTW (https://polymatto.com/about, @polyMatto on X) — engineer for two decades+, Italy to London and now raising my young family in exile, surrounded by trees and/or beach as much as possible, trading floors to web3 infra and everything in between, now spending my open-source time directing clankers in various ambitious projects adn no, this one wasn't ambitious at all, just useful and one that I am expecting to "flop" in here since it's literally my first post. I know, I should feel ashamed!
But more is coming soon, wintty is probably going to be my next post. Stay tuned!
Happy to answer anything and to intercept the, hopefully, fresh virtual tomatoes you'd throw at me.
Ciao!
Hi Alessandro. Great post! Stunt looks very interesting. You clearly put a lot of thought into the offline behavior, deterministic runs, sandboxed adapters, and real-SDK conformance. I just gave it its first star.
I recently open-sourced Vyral and posted it to Show HN. It approaches an adjacent problem from a different direction: stable application-level contracts with adapter behavior qualified against explicit evidence, so application code can be written in a provider-portable manner. https://github.com/Univeracity/vyral
The two projects appear quite complementary. Stunt could play a role in deterministic pre-qualification tests around provider adapters, while remaining distinct from live-provider qualification. I'm curious about which provider behaviors you think are worth promoting into reusable capability contracts and which should remain intentionally provider-native.
If that sounds interesting, perhaps we should explore a collaboration. No agenda beyond that. Congratulations on shipping!
Thanks Jeremy, first star appreciated! On your question: my line so far has been that anything a client can't distinguish in a test suite belongs in the mock (state machines, pagination, signature schemes), but the semantics stay provider-native.
A Stripe refund and an Adyen reversal aren't the same object, and abstracting them is how payment integrations get burned IMHO. The one place I'd promote to a shared contract is cross-cutting shape: cursor pagination, idempotency keys, webhook signature verification, retry-after semantics. Vyral's evidence-qualified adapters sound like the other half of that — offline simulation vs live qualification if I am getting it right. If I were you I'd add a demo or something to Vyral's README, make it shorter, like progressive disclosure with all the nice details on the website (link it so agents can find it). Show the money shot, if that makes sense.
I am going to look into Vyral in more depth because I am intrigued. I'll reach out if anything comes to my mind. If you have any ideas about how a collaboration could look like, feel free to hit me up! I mean, we are already collaborating in a way :)
Thanks again for this, I appreciate it.
[dead]