Api-Forge

One sentence in, a full REST API out

Comment

Inspiration

Every frontend build starts the same way: you need data before you can build UI, and you need a backend team (or hours of your own time) to design a schema, seed realistic records, and stand up endpoints before you can even start. Mock tools like Mockoon or Beeceptor help, but most of them still need an existing OpenAPI spec or real traffic to learn from. We wanted something that starts from nothing but a sentence: describe the backend in plain English, get back a real, running API.

What it does

You type something like "a hotel booking system with rooms, guests, and reservations" and API-Forge:

  1. Infers the entities and their fields
  2. Generates realistic seed data for each entity
  3. Builds full CRUD routes and mounts a live FastAPI sub-app at /api/{api_id}

What comes back isn't a mockup of an API, it's an actual FastAPI app with real Swagger docs, an entity relationship diagram, a request playground, and OpenAPI export. Two forged APIs can run side by side without touching each other, and everything persists in SQLite so it survives a server restart.

How we built it

The core is a three-step LangChain pipeline running on Groq (llama-3.3-70b-versatile):

  • Schema chain: prompt to structured EntitySpec[] output
  • Seed chain: entities to realistic seed records
  • Route chain: entities to CRUD RouteSpec[], generated deterministically rather than by the LLM

Splitting the pipeline into three inspectable steps instead of one opaque prompt-to-JSON call was a deliberate choice. If something goes wrong, we can tell exactly which stage produced bad output, and each stage can be tested and retried independently. Each generated API gets a per-api_id FastAPI sub-app mounted at runtime, backed by a SQLite store with an in-memory cache in front of it for speed.

On the frontend, a split hero layout takes the prompt, and once forging finishes, a full dashboard appears: stats, an ER diagram, a schema breakdown, and a live playground for hitting real endpoints without leaving the page. A Three.js wireframe animation runs in the background purely for atmosphere.

We split the work by strength: schema, seed, and route chains, the FastAPI serving layer, and most of the pipeline hardening on one side; retry logic and a chunk of the frontend dashboard on the other.

Challenges we ran into

Structured output isn't always structured. Groq's function-calling output occasionally fails to parse cleanly, especially on longer completions, seed data generation was the worst offender since it returns the most tokens. One clean retry with a short delay catches the vast majority of these transient failures without masking a real, repeated problem: if every attempt fails, that's surfaced as an actual error instead of silently swallowed.

Environment drift. Python 3.14 broke several dependencies we hadn't expected trouble from: pydantic, bcrypt, and a couple of LangChain packages all had compatibility issues that needed resolving before the pipeline would even import cleanly.

Keeping generated APIs actually isolated. Mounting each forged API as an independent sub-app, rather than routing everything through one shared FastAPI instance, took more care around route registration and Swagger doc generation, but it's what makes running two unrelated APIs side by side safe.

Deterministic vs. generative boundaries. We deliberately kept route generation deterministic instead of LLM-driven. It's less flexible, but far more reliable, one fewer place for the pipeline to produce something the server can't actually serve.

What we learned

Splitting an LLM pipeline into small, single-purpose, independently testable steps pays off almost immediately: it's easier to debug, easier to add retry logic to just the flaky parts, and easier to reason about than one big prompt trying to do everything at once. We also learned, the hard way, that "structured output" from an LLM API is a strong guarantee, not an absolute one, and that production-shaped code needs to plan for the occasional malformed response instead of assuming it away.

What's next

  • LLM-assisted relationship inference between entities (foreign keys, not just flat tables)
  • Auth scaffolding per generated API
  • Export to a deployable standalone FastAPI project, not just an OpenAPI spec

Built With

Share this project:

Updates