Guides / Concepts explained

What Is an API? A Plain-English Guide for App Builders

An API is how one piece of software asks another for data or an action. How REST APIs, endpoints and API keys work, with examples and what to ask your AI.

Mythex Team · 2026-09-29 · 5 min read

An API (application programming interface) is a defined way for one piece of software to ask another for data or to get it to do something. Your app sends a request in an agreed format — "give me tomorrow's bookings," "charge this card €20," "summarise this text" — and the other system sends back a structured response. APIs are how the pieces of an app talk to each other, and how your app uses outside services like payments, email, maps and AI.

Why APIs matter when you build with AI

Almost every useful app is made of parts that communicate through APIs:

• Inside your app, the screens in the browser call your own backend's API to load and save data.
• Outside your app, your backend calls other companies' APIs: Stripe to take payments, an email provider to send receipts, an AI model provider to generate text.

When you ask an AI builder to "take payments" or "add an AI summary," what it's really doing is writing code that calls an API. Knowing the basics helps you understand what the AI needs from you (usually an account with that service and an API key), where things can go wrong, and what they'll cost.

An everyday analogy

Think of a restaurant. You don't walk into the kitchen and cook. You read the menu, tell the waiter what you want in a way the kitchen understands, and the waiter brings back your food — or tells you the dish is sold out.

• The menu is the API documentation: a list of what you can ask for and how.
• The waiter is the API: the one agreed way requests get in and responses come out.
• The kitchen is the other system: you don't need to know how it works inside.
• Your order is the request; the plate is the response.

The kitchen can change its ovens and staff without affecting you, as long as the menu stays the same. That's the real value of an API: it lets two systems work together without either needing to know how the other is built.

How a web API request works

Most APIs you'll meet are web APIs that work over HTTP, the same protocol your browser uses. Each request has a few parts:

And each response has:

JSON (JavaScript Object Notation) is a simple text format of names and values in curly braces. It's the standard way web APIs exchange data.

REST: the most common style

REST is a widely used convention for designing web APIs. Each type of thing gets its own URL, and standard methods say what you're doing to it. Here's what a REST API for a booking app might look like:

PUT also exists and conventionally replaces a whole record, while PATCH changes only the fields you send.

Status codes you'll see most often:

When your app breaks, the status code is often the fastest clue. A 401 from a payment provider usually means a missing or wrong API key; a 429 means you're calling too often.

REST isn't the only style — GraphQL and RPC-style APIs exist too — but REST is what most services and AI-built backends use.

A worked example: a booking confirmation

When a customer books a haircut in a salon app, several API calls may happen in a second or two:

1. The booking page in the browser sends POST /api/bookings with the service, time and customer details to your backend.
2. Your backend checks the slot is free, saves the booking in the database, and returns 201 Created.
3. Your backend calls an email provider's API with its secret key: "send this confirmation to lena@example.com."
4. If there's a deposit, your backend asks the payment provider's API to create a checkout session and sends the customer there.
5. Later, the payment provider calls your app to say the payment succeeded. That reverse call is a webhook.

The first two steps are your own API between frontend and backend. Steps 3–5 are third-party APIs.

Common terms explained

Common mistakes and misconceptions

• Putting secret keys in the frontend. Anything in code that runs in the browser can be seen by anyone who visits. Secret keys must stay on the server, in environment variables or secrets.
• Pasting keys into chat. Chat history may be stored. Use your builder's secrets feature instead, and rotate any key you've exposed.
• Assuming an API is free. Many APIs charge per request or per unit of usage — AI model APIs charge by tokens. Check pricing and set spending limits. See how to use LLM APIs.
• Not handling failure. Outside services go down, time out and hit limits. Ask for sensible error messages and retries.
• Trusting the browser. Your own API must check permissions itself. Hiding a button doesn't stop someone calling the endpoint directly.
• Using live keys while testing. Use test mode keys until you're ready to launch.

What to ask your AI builder for

• "Which outside APIs does this app use, and what does each one cost?"
• "Call the payment API from the server only. Read the key from an environment variable."
• "List every endpoint in our API, what it does and who is allowed to call it."
• "Check on the server that the logged-in user owns the booking before updating or deleting it."
• "If the email API fails, save the booking anyway and log the error."
• "Use the provider's test mode for now."

APIs in Mythex

Mythex can build your own API — as part of a web app, or as a separate backend in Node, Python (FastAPI), C# or Java running alongside your frontend — and write the code that calls outside services. You add their keys as project secrets rather than in chat, and they're available to your app in the preview and once published. The docs have recipes for integrating any API and building a REST API backend.