API Maker
The backend engine for the AI era
Code scanEpisode 64 8:41 12 chapters October 2026
The APIs Security Report of API Maker reads the code of your account in TypeScript, Python, PHP, C#, Go, Rust, Java and Kotlin, finds what it leaks on its own at its line, and fixes it in one click, in the language it is written in. On Calm Home: TLS checks off, SQL put together from the request, a key in the code, and row scoping hooks graded, rewritten and written in Python and Go.
In the playlists The complete course Security & access
The security report now reads your code, in all eight languages API Maker runs. It finds what the code leaks on its own, at its line, and fixes it in one click, in the language it is written in.
Settings are only half of the story. The code decides what an API does, and it can leak on its own : a key written in the code, SQL put together from the request, a call with the checks of TLS off, a hook that trusts the body. And the code of one account is written by several teams, in several languages, by people and by AI assistants. A reviewer reads one or two of them.
API Maker reads all eight, points at the line, shows the fix before it is saved, and saves it through the page of the code. In this video : the code of Calm Home, the scan of the code and its rules, a fix seen before it is saved, SQL and secrets, hooks in every language, a public API, and what it means for AI assistants.
Calm Home has grown. The warehouse team syncs the stock of a partner, in Python. The marketing team exports the newsletter subscribers, in PHP. The payments team refunds orders, in Go. The support tool searches orders, in TypeScript. And the support team rewrote the hook of support tickets, in Python. Every piece works, and every piece was reviewed by somebody who reads its language.
In the report, scan again. The scope now counts the pieces of code it read, and their languages. And a new category, Code, asks one more question : what does the code itself leak, in every language? How does one report read eight languages? The scan gathers every piece of code of the account : custom APIs and the hooks of their versions, the hooks of tables and of system APIs, schedulers, events, WebSocket events, utility classes, initializers, migrations, and the functions of auth providers.
A reader of tokens knows the strings, the comments and the templates of each language. Its rules read the tokens, and every hook is graded the same way, whatever it is written in. Nothing is run : the code is read. The rules, in six families. Secrets and tokens : a key in the code, a secret or a token returned, a token in the logs, an error stack returned.
Rows : the users table read with its passwords, a filter written by the caller, the rows of persons read unscoped, a row by an id the caller sends, the body written as it is. Injection : SQL, commands, code made at run time. Network and files : an address the caller chooses, a file the caller names, the checks of TLS off. Crypto : weak password hashes, and random tokens that can be guessed.
And hooks : one that changes who the caller is, and one that a caller turns off.
Open the finding of Partner stock sync. The head names the custom API, the line, six, and the language, Python. The evidence shows the line as it is written : verify equals False. And the fix is one button : turn the checks of TLS back on. Click it. Before anything is saved, the dialog shows the code now, on the left, and after the fix, on the right : one word changes, on line six.
Apply and scan again : the code is saved, and the next scan lists the finding under Fixed. Where does the fix go? Into the code of the custom API, and into its version in use, which is the code that runs. The same for a scheduler, or a listener of an event. A hook of a version of a custom API is changed in that version. Then the code is saved through the route of its own page : compiled and checked as when you save it there, including the rule of one language per API.
It goes to git and to the local client, and the account is scanned again. And if the code changed since the scan? A fix carries a fingerprint of the code it was made for. When the code changed elsewhere, the fix still lands, as long as the text it replaces is still at its place. Otherwise it is refused, and the report asks for a new scan. A fix never lands on code it was not made for.
The export of the marketing team, in PHP : SQL is put together from what the caller sends. Critical. The line pastes the parameter since into the text of the statement. How it is exploited names this very API and this very parameter : one value ends the text and adds SQL of its own. The remedy says how : read with g.sys.db and a find, where API Maker binds every value.
In the Go of the payments team, the code holds a secret. The report never shows it : the value is masked, on the page and in the report in git. The suggested code reads it from Secret Management, in Go, and the remedy says to rotate it : it has been in git.
Now the hooks. A hook decides whose rows a request reaches, and API Maker runs hooks in eight languages. The report reads every one of them the same way.
Support tickets is scoped for some APIs only. The card of the hook says Python, and the report reads it as it reads TypeScript : it reads the person and filters get all, but not query, and merges with a spread. Rewrite the hook to cover every API shows the code now and after, in Python. The hook keeps its name, its groups and its place. Apply, and support tickets is scoped for every API.
Orders has no hook yet. Add a row scoping pre-hook opens on its settings ; its Code tab offers the eight languages. When hooks already run for a table, their language is taken, and locked : one API runs the code of one language. Here, none does, so pick Go. The code is written again in Go, and the chips say what the report reads in it : it scopes rows, for every family of APIs.
Apply : the pre-hook is added, in Go. Some fixes are one idea in eight languages. A hook without the guard of the internal calls also scopes custom APIs, schedulers and events, which carry no person. Let the internal calls through adds one guard at the top of main, in the language of the hook, and changes nothing else. Is the code the report writes right, in every language? The row scoping hook is run by the runner of each language, against every family of APIs : get all, query, update many, saves, aggregate, and a call without a person.
And the API test sheets add it from the report, call orders as two customers through it, rewrite it and guard it, in each of the eight languages.
Store status answers without a token. That is fine for a health check, worth a look for anything else. Require a token changes one word of its Basic Info, seen first, and every caller needs a token again.
This matters even more with AI assistants. They write code in any language, and fast. The report reads it like any other code, writes the line and the fix into report.md, in git, and the next scan grades what the assistant changed.
Best practices. Keep secrets in Secret Management, never in the code. Never put a value of the request into the text of SQL. Keep the checks of TLS on. Never let a caller write a filter alone. Use the generated hook, in the language of your API. And read every fix before it is saved : the dialog shows it.
That was the scan of the code. Every piece of code, in eight languages. Every rule, at the line. Fixes seen before they are saved, and made where the code is kept. Hooks graded, rewritten and written in your language. Next, the other security features. API Maker. Build faster, spend smarter, deliver better.
Length 4:29Security
Length 11:21Security report
Length 4:44Languages
Length 6:01Hooks