I built a small tool that converts API logic written in plain .txt files into real, executable PHP API endpoints.
The motivation was personal: I can design and ship frontends quickly, but backend APIs (setup, boilerplate, deployment) always slowed down small projects and MVPs. I wanted a way to describe inputs, rules, and responses in text and get a working endpoint without worrying about infrastructure.
This is early and opinionated. I’m especially interested in feedback around:
trust and security concerns
where this breaks down
whether this is useful beyond prototypes
Happy to answer questions about how it works.
Is the .txt parsed into a constrained schema, or is it closer to free-form instructions that get interpreted at runtime?
Related to that, how are security boundaries enforced? For example, preventing arbitrary code execution, file access, or unintended side effects if the text is malformed or malicious.
Feels potentially very useful for prototyping, but I’m trying to understand where the hard limits are.
The .txt file is never executed directly. We pass the text to our system, generate backend code in PHP from it, and save that as a separate file. When someone calls the API, they’re actually hitting the generated .php endpoint behind the scenes, not the text file.
Right now this is a beta, so security hardening is still in progress. The plan is to run generated APIs in a restricted environment, isolate them from the main system, and limit filesystem and external operations. Those guardrails aren’t fully in place yet.
At the moment, this is best suited for simple prototypes, internal tools, and basic APIs. We’re intentionally starting there and pushing the limits gradually as we tighten security and execution boundaries, with the long-term goal of supporting more serious and eventually enterprise-level use cases.