Builder School — USE APIs TO ADD POWERFUL FEATURES TO YOUR PRODUCT

MODULE 01

Open book · Understand the connection first

Understand APIs
before you use them.

An API lets your product ask another service for a capability or information. In this module, you are learning the idea first so later API work makes sense instead of feeling like a mystery.

MODULE 01 · OPEN BOOK

Learn what an API does before you connect one.

Products often need abilities that come from somewhere else: maps, payments, weather, messages, A.I., shipping information, search, or other services. An API is one common way a product can ask an outside service for those abilities or information in a controlled way.

OPEN BOOKThe full study guide stays on this page while you answer. The goal is understanding, not memorizing technical vocabulary.

01Your ProductNeeds something

02API RequestAsks the service

03Outside ServiceDoes its job

04API ResponseSends a result back

05Your ProductUses the result

What Is an API?

API stands for Application Programming Interface. In plain language, an API is a controlled connection that lets one software product ask another software service for information or for a capability it provides.

Your product does not need to become that outside service. It sends a request using the rules that service provides. The service handles the request and sends a response back. Your product then uses that result.

Example: A travel product can ask a map service for directions instead of building its own worldwide map system. A store can ask a payment service to process a payment instead of becoming a bank.

Why this matters: When you understand that an API is a connection between software systems, later instructions about “connecting an API” become much easier to follow.

Open-book answer:An API is a controlled connection that lets my product ask another software service for information or a capability and receive a result back.

How Is an API Used?

A product uses an API by sending a request to an outside service. That request tells the service what the product needs and may include information the service needs to do the job. The outside service processes the request and sends a response back.

The product then decides what to do with that response. It might display information, complete an action, save a result, show a map, send a message, return an A.I. answer, or continue a user workflow.

Some APIs require an API key or another form of permission. Think of that as an access credential that identifies which product is allowed to make the request. Different APIs also have their own rules, limits, costs, and allowed uses.

Simple flow: Your product asks → the API carries the request → the outside service does its job → the response comes back → your product uses the result.

Why this matters: The API is not the feature by itself. The feature comes from how your product uses the outside service's response.

Open-book answer:My product sends a request to the outside service, the service sends a response back, and my product uses that result to show information or complete an action for the user.

Why Is an API Used?

An API is used when your product needs useful information or a capability that another service already provides. Instead of rebuilding that entire outside system, your product can connect to it and use the part it needs.

This can make a product more powerful and can save time. APIs can give a product access to specialized services such as maps, payments, A.I., email, text messages, shipping, calendars, search, weather, or business data.

Using an API also creates a dependency on that provider. The service can have usage limits, costs, outages, security rules, privacy requirements, or changes. A strong builder understands both sides: an API can add power quickly, but the product still needs to use that outside service responsibly.

Why this matters: You should connect an API because it serves a real product need—not just because an API sounds advanced.

Open-book answer:An API lets my product use a capability or information another provider already offers instead of rebuilding that whole outside service from scratch when it serves a real product need.

RememberAn API is a controlled software connection. Your product makes a request, another service responds, and your product uses the result. The reason to use one is to add a needed capability or information without building that entire outside service yourself.

Your understanding checkAPI Foundations — Open Book

Saved

Carried forward from Course 4Your Complete Product State Is Still With You

Automatic · Nothing to re-enter

Checking Course 4 completion.

Complete Course 4 forwarding state

Complete Course 4 first.

Open bookExplain the three API ideas

Use the study guide

Open-book understanding checkUse the matching open-book answer from the study guide in each answer box. Then click Check My Understanding once.

1. What is an API?Explain the connection between your product and another software service. 2. How is an API used?Explain the request → response → product result flow. 3. Why is an API used?Explain why a product may use an outside capability instead of building that whole service itself.

Check your understandingAPI Foundations Check

One final check

Course 5 · Module 1

Use the study guide to complete the questions, then check your understanding.

What: Waiting for your answer.
How: Waiting for your answer.
Why: Waiting for your answer.

Use the three open-book answers from the study guide, then press Check My Understanding once.

MODULE 02

Guided example · Improve an app that already works

How to Use ChatGPT
to Connect an API.

The Simple Expense Tracker is already a good, useful app without an API. Now Builder School shows how one API can improve that same app by adding receipt scanning—without replacing the simple manual expense flow that already works.

MODULE 02 · RECEIPT SCANNING API

Watch one useful API improve the same Expense Tracker you have followed from the beginning.

The app already lets a person type a name, amount, and category and save an expense. That is a complete useful product. An API is not being added because the app is bad or broken. It is being added because receipt scanning can make an already-good app faster and easier to use.

THE POINTA good app does not need an API just to sound advanced. Add an API when it creates a real improvement. Here, the manual expense flow stays available, while receipt scanning gives the user a faster option.

BEFORE APIManual entry already works.

The user types the expense name, amount, and category, then saves it.

WITH APIScan a receipt to prefill the expense.

The user takes or uploads a receipt photo. The receipt-reading service returns useful receipt information so the app can prefill the expense for review.

Start with the working Expense Tracker.

Keep the existing manual Add Expense flow. The API is an improvement, not a replacement for the simple product that already works.

Add one clear new ability: Scan Receipt.

A new Scan Receipt action lets the user take or upload a receipt image instead of typing every detail by hand.

Let the receipt API do the specialized reading.

After the builder verifies the provider's official documentation, the app sends the receipt image according to the provider's rules. The service reads available receipt details such as merchant, total, date, and line-item information.

Use the API response to prefill the Expense Tracker.

Merchant becomes the expense name, total becomes the amount, the receipt date is shown when available, and the app suggests one existing category: Food, Gas, Bills, Shopping, or Other. The user reviews the result before saving.

Verify that both ways still work.

Test a readable receipt, a difficult or unreadable receipt, the manual-entry fallback, saving and deleting expenses, Total Spent, and the existing categories. The API upgrade passes only when the old app still works too.

The lesson to rememberWorking app → useful improvement → official API source → complete AI direction → receipt response → user review → save → failure test → regression test.

Guided exampleSee How Receipt Scanning Improves the Expense Tracker

Read only

Carried forward automaticallyThe Same Simple Expense Tracker

Nothing to re-enter

Waiting for Module 1.

See the carried-forward Course 5 state

Complete Module 1 first.

Step 1 · Complete AI directionReceipt Scanning API Build Request

Builder School prepared it

This request tells AI that the current app already works, defines the one approved improvement, requires official provider information, protects credentials, keeps manual entry, and requires the new receipt path plus the old app to be tested.

Complete guided requestThis is a teaching example. You do not need to copy or send it anywhere.

Step 2 · Complete proofExample Result After Receipt Scanning Is Tested

Evidence, not a claim

A good result proves the scan improved the app without breaking what already worked. It checks receipt reading, user review before save, failure fallback, manual entry, totals, deletion, categories, and the existing saved-expense flow.

Guided connection resultThis is a controlled teaching example, not a live call to a receipt provider.

01App already workedManual entry remains available.

02Official source usedNo guessed provider setup.

03Scan is reviewedThe user can check the extracted details before saving.

04Regression checkedTotals, delete, categories, saving, and manual entry still work.

FinishConfirm Your Understanding

One simple action

You do not need to memorize API code. Remember the product lesson: the Expense Tracker was already useful without an API. Receipt scanning is added because it saves the user work, while the original manual path stays available.

Review how receipt scanning improves the same Expense Tracker, then confirm when the process makes sense.

USE APIs TO ADD POWERFUL FEATURES TO YOUR PRODUCT