APIs and endpoints

API may be one of the most frequently used and least clearly explained terms in technology.

But you already have the foundation.

In Module 4, you learned that clients send requests and servers return responses, and in Module 5, you learned that products contain separately built parts: frontends, backends, internal tools, and third-party services.

An API is what allows those separate pieces of software to interact in a defined and predictable way.

What is an API?

APIConcept · lights on your mapAPIApplication Programming Interface: a defined way for one piece of software to request information or capabilities from another, like a restaurant menu of what can be ordered. The requester uses the interface without seeing the provider’s internal code. stands for Application Programming Interface.

An API is a defined way for one piece of software to request information or capabilities from another piece of software.

A useful analogy is a restaurant menu. The menu describes what you can order and what information you need to provide. Instead of entering the kitchen or telling the cooks how to prepare the meal, you choose from the options the restaurant has made available.

An API plays a similar role between software systems, describing which requests another system can make, what information each request requires, and what kind of response it can expect.

For example, a payment provider’s API might allow an application to:

• Attempt a payment
• Look up a transaction
• Issue a refund
• Retrieve a payment’s status

A mapping API might allow an application to:

• Search for an address
• Retrieve coordinates
• Calculate a route
• Estimate travel time

The application uses the available interface without needing access to the provider’s internal code or infrastructure.

APIs are a form of abstraction

In Module 1, you learned that abstraction hides unnecessary internal complexity behind a simpler interface.

An API is an abstraction between software systems.

A coffee application does not need to understand every step involved in communicating with banks and card networks. It sends a supported request to a payment provider’s API and receives a response.

The provider decides what happens behind the interface. It may contact banks, run fraud checks, record the transaction, and perform many other operations.

The coffee company only needs to understand:

• Which request to send
• Which information to include
• How to prove that it is authorized
• What responses may come back
• How to handle success and failure

The API creates a boundary. One side promises to accept certain requests, while the other side agrees to send those requests in the expected form.

APIs inside a product

APIs are not used only between different companies. A product’s own frontend often communicates with its backend through an API.

Suppose a user opens the coffee app and views order number 1042. The frontend might send a request to the backend resembling: GET /orders/1042

The backend’s API receives the request, retrieves the order, and returns the relevant information.

When the user places a new order, the frontend might send: POST /orders with the order details in the request body.

The backend validates the request, applies business logic, stores the order, and returns a response.

In this case, the API is the defined communication surface between the frontend and backend.

Internal and external APIs

An internal API is intended primarily for systems within the same company.

For example, the coffee company’s support dashboard might use an internal API to look up an order or issue a refund.

An external API is made available to software outside the organization.

A payment company may offer an external API that its customers use to process transactions.

Some external APIs are public and available to many developers, while others are available only to approved partners or paying customers.

The distinction describes who the API is intended for, not necessarily how the underlying communication works.

Web APIs

APIs can take several forms, but this module focuses mainly on web APIs.

A web API uses web technologies such as HTTP to exchange requestsConcept · lights on your maprequestRe-encounter from Module 4. The same HTTP request, now machine-to-machine: no person browsing, one system calling another. The backend that serves the frontend becomes a client when it calls a payment provider. and responsesConcept · lights on your mapresponseRe-encounter from Module 4. The same HTTP response, now returned to another program rather than to a browser. Its status code is read by code, not a person..

That means the conversation has the same structure you learned in Module 4:

• A client sends an HTTP request.
• The request contains a method, path, headers, and sometimes a body.
• The server processes the request.
• The server returns an HTTP response.
• The response contains a status code, headers, and sometimes a body.

The backend can become a client

Imagine that the coffee app’s backend receives a request to place an order.

During that one operation, the backend might need to:

• Ask a payment provider to charge the customer
• Ask a messaging provider to send a confirmation
• Notify the café’s order system
• Retrieve information from another internal service

The backend is a server when it answers the frontend’s request. But it becomes a client when it sends a request to the payment provider.

This reinforces an important idea from Module 4: client and server are roles within a particular interaction.

A single system can be a server in one conversation and a client in the next.

What is an API endpoint?

An API endpointConcept · lights on your mapAPI endpointA specific capability exposed through an API, commonly identified by an HTTP method plus a path (GET /orders/1042, POST /orders). The path identifies the resource or area of the API; the method communicates the action. is a specific location through which an API offers a particular capability.

In a web API, an endpoint is commonly identified by an HTTP method and a path:

The path identifies the resource or area of the API, while the HTTP method communicates the general action being requested.

Together, the method and path identify the endpoint. For example, GET /orders/1042 and DELETE /orders/1042 use the same path but represent different requested actions.

The server’s engineers decide exactly what each endpoint does.

Reading an API request

Consider this simplified request:

You can already read every major part.

The backend might return:

An API conversation is not a new kind of communication. It uses the same request-and-response structure you have already learned.

One user action can trigger many API calls

When a customer taps Pay, it may appear that one action occurred, but behind the scenes that action can begin several connected conversations:

1. The frontend calls the coffee company’s order API.
2. The backend calls a payment provider’s API.
3. The backend saves the order.
4. The backend calls a messaging API.
5. The café’s system retrieves or receives the new order.
6. The backend responds to the frontend.
7. The frontend displays the confirmation.

One user action can therefore fan out into many machine-to-machine requests.

Each system sees only the interface exposed by the systems it communicates with, without needing to understand all the internal details on the other side.

An API is also a contract

An API does more than make a capability available. It establishes expectations between the systems using it.

The API may define:

• Which endpoints exist
• Which methods they accept
• Which data must be provided
• Which data types are expected
• Which headers are required
• Which responses and status codes may be returned
• Who is allowed to make the request
• How failures should be handled

These expectations form an API contract.

If one side changes the contract without preparing the other side, the integration may break.

For example, if an endpoint suddenly changes a field from a number to a string, software expecting the old format may fail.

You will explore API documentation, contracts, and versioning later in the module.

The mental model to remember

An API is a defined interface through which one piece of software can request information or capabilities from another.

A web API uses HTTP requests and responses for that communication.

An API endpoint is a specific capability exposed through the API, commonly identified by an HTTP method and path.

An internal API connects systems within an organization, while an external API is made available to outside systems.

APIs are abstractions. They allow software to use another system’s capabilities without knowing how that system works internally.

You should now be able to recognize that a frontend calling its backend and a backend calling a payment provider are variations of the same pattern. One system sends a request to another system’s API and receives a response.