The problem:
Every sprint I'd start building against an API that didn't exist yet. The options were bad: remain blocked until the backend shipped, build against hardcoded JSON that drifts the moment something changes, or maintain a local mock nobody else was using.
The frustrating part — the spec usually exists, you just can't run it. I believe QAs hit the same challenge with writing integration tests against an endpoint that isn't live. And the longer this goes, the more testing gets compressed into the last 48 hours of a sprint.
What Mockline does:
Upload an OpenAPI 3.0 spec (YAML/JSON or remote URL). Mockline builds a Docker image with the Contour CLI baked in(https://contour.trillionclues.dev), spins up a container, and assigns a public URL — live mock server with real HTTP responses in 3-7 seconds.
Also each mock is isolated per spec version. You can run contract tests to validate the mock matches the spec, and diff two versions to catch breaking changes before production.
What's working:
> Spec upload and versioning
> Mock server provisioning public URLs
> Start/stop/delete controls
> Contract testing and schema diffing > In-dashboard API client to hit endpoints in real time
Honestly, I'd genuinely love feedback on
1. Is "upload spec, get live mock" the right abstraction, or do teams want Postman-style manual response definition?
2. Would you use this for integration testing in CI, or is a 3-7s cold start too slow for that?
3. Anyone building against gRPC or GraphQL specs? That's on the roadmap but I want to know if it's actually a blocker too.
Would genuinely appreciate any feedback — especially from QA engineers or anyone who's tried to solve this a different way.
mockline.xyz — waitlist at mockline.xyz/waitlist