Chapters

What you will learn

Find the failing call in Log Explorer
Request, response, console and cURL, then replay it
The stack names the line, in one error format for every language
Test the hook alone, run it unsaved, then save
Console Logs View, x-am-meta, and the queries of one call
Debug Settings: stopped on your line, safe by design
Native Process Logs, and why the standard keeps AI code honest

Transcript1222 words · click a time to play from there

Intro

Something broke at checkout. In this video, you will follow one real bug, from the failing call to the line that broke, with every debugging tool of API Maker.

Logs in five places

Debugging a backend usually means logs in five places. You open an SSH session to tail a log file, run docker logs on the right container, query a log aggregator, read the slow query log of each database, and when nothing helps, you add a print, redeploy, and wait. API Maker keeps the failing call, its error with your line, its logs and its queries in one panel, and gives you real breakpoints, without opening a port.

Here is the plan. Find the failing call. Read the stack. Test one hook alone. Follow the logs. See the queries. And stop on a breakpoint.

The bug reports

Calm Home's checkout calls Cart Quote, a custom API in TypeScript. It reads the prices from MongoDB, the coupon from MariaDB, and answers the subtotal, the discount, the shipping, and the total. Shipping is free from one hundred and fifty dollars. Last week, an AI assistant added a pre hook, Normalize cart, which upper cases what customers type. On Monday, support sends two reports. Checkout fails for some carts. And one customer paid shipping on an order of exactly one hundred and fifty.

Find the call

Start where it failed. The log profile, named Checkout, logs Cart Quote, so every call of the storefront is written to the log database. Open Log Explorer, and click Failures : only the failing calls are left. Open one. Status five hundred : cannot read properties of undefined, reading trim. Request holds the headers and the body the storefront sent : this cart has no coupon. Response keeps the answer, because a failed call is always saved.

cURL copies the whole call. And on a call that worked, Console shows the g.logger lines of its code. Paste the command in a terminal, and the failure comes back, every time. A bug you can replay is half fixed.

Read the stack

To work on it, open Custom API, and Test API on Cart Quote. Paste the body of the failed call : three candles, and no coupon. Send. The answer is the standard error of API Maker : success false, the status, and the errors. Its stack lists only your code, and names the culprit : the pre hook Normalize cart, line five. Every API answers its errors in this one envelope, in all eight languages.

A Python error names its file and its line the same way. No framework frames, no lines of compiled code. Your clients handle one format, and an AI assistant that reads the error knows exactly where to look.

Test Hooks

Now test the hook alone. Tick Test Hooks : API Testing picks the version and the hook, and the Code tab shows the code of the hook. Send runs only this hook, with the body you typed : no API, no other hook. Same crash, and line five is underlined in red. The coupon is optional, so add a question mark. Command E runs the code on screen, before it is saved : no error, and the Logs tab shows the cart, normalized.

Command S saves the hook, and saving is deploying.

Logs

Now the second report. Send the customer's cart : a wall clock, a teapot and two candles, with the coupon welcome five. Shipping : nine dollars ninety. The Logs tab tells the story in order : the line of the hook, then the line of the API. The subtotal is one hundred and fifty. It is right, so the rule is wrong. console.log goes somewhere else : to Console Logs View, in the top bar.

It gathers what the code of the account prints, from every sandbox and every server, and refreshes itself every five seconds when you ask. Compile errors of Go, Rust, C#, Java and Kotlin land here too. So remember three channels. g.logger lines travel with their request : the Logs tab while you test, the Console tab of Log Explorer in production. console.log goes to the console of the account. And code on the native process prints to the output of the server.

Queries

Set x-am-meta to true, and send. The answer now carries a meta block : the execution time measured by the server, which server, process and port ran the code, on which runtime, and which groups allowed the call. And what did the code ask the databases? The Index Maker tab lists the calls of this run. One query on MongoDB products, one on MariaDB coupons, both on an index, with their count, their rows and their time.

A query in a loop shows up here at once. API Maker also runs queries of its own while it serves a call : a deep populate across databases, a unique check. A scanning period records them when Log internal queries is on. The order page of the storefront asks MySQL for orders, with their customers and their coupons. The analysis shows the query on MySQL, and the ones API Maker ran on PostgreSQL and MariaDB.

Breakpoints

Logs tell you what happened. A breakpoint shows it happening. Open the user menu, then Debug Settings, and switch it on. Not saved yet : Save restarts all your sandboxes, ready for a debugger. Run Cart Quote once. Its debug sandbox starts, and shows up in the dialog by itself, with its debug port, its direct address, and the command of the SSH tunnel. For Node, attach Chrome DevTools : open chrome://inspect, add the address under Configure, and click inspect.

Write debugger before the shipping line, and send again. The request waits, and DevTools stops on your line. Scope says subtotal : one hundred and fifty, exactly. Step over : shipping becomes nine ninety, because greater than leaves one hundred and fifty out. A paused request may wait up to an hour. On a real server, the inspector listens on 127.0.0.1 only, never on the network. The SSH tunnel brings it to port 9229 of your laptop, where chrome://inspect finds it.

Bun sandboxes work too, with the web inspector of Bun, or the Bun extension of VS Code. Code on the native process cannot be debugged. Resume, and the answer arrives. The fix is one character : greater or equal. Command E : shipping zero. Command S saves it, live on every server. Then switch debugging off, and save.

Native Process Logs

And when the server itself has something to say, Native Process Logs reads the output file of any server of the installation. Reload it, follow it every five seconds, or download the whole file. No SSH.

The standard

Both bugs are the kind an AI assistant writes in seconds. API Maker keeps that code on the standard : one error format, the hook and the line in every stack, logs tied to their request, and the same answers, whether a person or an assistant reads them. Then lock the fix with a test case, as in the previous episode.

Recap

From a failing call to the line that broke. Log Explorer found the call. The stack named the line. Test Hooks isolated the hook. Logs and queries explained the number. And a breakpoint proved it. Next, we take this code into your own editor, with the local client and VS Code. API Maker. Build faster, spend smarter, deliver better.

Debug an API from the Failing Call to the Line That Broke