How APIs work in AI-built applications

What is in a request?

The response comes back with a status code, headers of its own, and usually a body in JSON. The status code is the part people skip and the part that tells you most.

Which calls does a typical AI-built app make?

• Browser → your own server functions, for anything that needs a secret or a permission check.
• Your server → your database, to read and write rows.
• Your server → third-party services: payments, email, AI models, analytics.
• Browser → your database directly, when the service supports it and access rules do the protecting.

Knowing which of these four a broken feature uses narrows a mystery to one of four places before you read a single line of code.

How do you see the calls your app is making?

1. 1Open your browser's developer tools and select the Network tab.
2. 2Reload the page or trigger the broken action.
3. 3Find the request that matters — filter by Fetch/XHR to hide images and fonts.
4. 4Read its status code first, then its response body.
5. 5Check the request headers: was an Authorization header actually sent?

This is the single highest-value skill on this page. Most 'the app is broken' reports resolve in under a minute once you have read the failing request.

What goes wrong most often?

Why is the response body worth reading?

Good services explain themselves. A failed request usually returns a JSON body naming the exact problem: a missing scope, an invalid parameter, an expired token. Generated code often throws that body away and shows a generic 'Something went wrong', which turns a five-second fix into an afternoon.

if (!response.ok) {
  const detail = await response.text();
  console.error("Provider failed", response.status, detail);
  throw new Error(`Provider failed [${response.status}]: ${detail}`);
}