How to Use a REST API: Beginner-Friendly Step-by-Step Guide
Updated:
May 10, 2026
To use a REST API, you send an HTTP request to an endpoint using the right method, headers, authentication, and optional parameters or JSON body, then read the response to confirm the action worked. In practice, this means choosing the right URL, telling the API what action you want to perform, passing the required credentials, and checking the response data or status code.
This guide walks through how to use a REST API from the ground up. You’ll learn how REST API requests work, how to make your first GET and POST requests, how REST API authentication works, how to read API documentation, and how to avoid the most common beginner mistakes.
What it means to use a REST API
A REST API lets one system communicate with another over HTTP. Instead of opening a website in a browser, you send a structured request to a specific URL and receive structured data back, usually in JSON format.
For example, an ecommerce platform might expose REST API endpoints for customers, orders, products, payments, and shipments.
When you use a REST API, you are asking the system to do something with one of those resources. You might request a list of orders, create a new customer, update a ticket, or delete an old record.
If you are still learning the broader API basics, UI Bakery also has a beginner-friendly guide on what an API is. This article focuses less on theory and more on how to actually call a REST API.
What you need before making your first request
Before you call a REST API, you usually need five things: an endpoint URL, an HTTP method, authentication details, parameters or body data, and API documentation.
For a beginner, the easiest place to start is usually a simple GET request. A GET request asks the API to return data without changing anything.
The 5 parts of a REST API request
Most REST API requests have five main parts: endpoint, method, headers, query parameters, and body.
1. Endpoint
The endpoint is the URL you send the request to.
Example:
https://api.example.com/customers
This endpoint might return a list of customers.
Another endpoint might return one specific customer:
https://api.example.com/customers/123
Here, 123 is usually the customer ID.
2. Method
The method tells the API what action you want to perform.
For a deeper comparison of CRUD actions and REST API patterns, see UI Bakery’s guide on CRUD API vs REST API.
3. Headers
Headers send extra information about the request. They often tell the API what format you are sending, what format you expect back, or how you are authenticating.
Example:
Content-Type: application/json
Authorization: Bearer your_token_here
Content-Type: application/json means you are sending JSON data.
Authorization usually contains your API key, bearer token, or other credentials.
4. Query parameters
Query parameters are added to the URL to filter or modify the request.
Example:
https://api.example.com/orders?status=pending&limit=10
This might ask the API for 10 pending orders.
Query parameters usually come after a ?, and multiple parameters are separated with &.
5. Body
The body is data you send with requests like POST, PUT, or PATCH.
{
"name": "John Doe",
"email": "john.doe@example.com",
"plan": "premium"
}
GET requests usually do not have a body. POST requests usually do.
How to make your first GET request
The simplest way to test a REST API is with curl, a command-line tool for making HTTP requests.
Here is a basic REST API request example:
curl https://api.example.com/customers
This sends a GET request to the /customers endpoint.
The API might return JSON like this:
[
{
"id": 1,
"name": "John Doe",
"email": "john.doe@example.com"
},
{
"id": 2,
"name": "Jane Smith",
"email": "jane.smith@example.com"
}
]This means the request worked and the API returned a list of customers.
A more realistic request may need headers:
curl -X GET "https://api.example.com/customers" \
-H "Authorization: Bearer your_token_here" \
-H "Accept: application/json"
Here is what each part does.
A successful GET request usually returns a 200 OK status code, response data in JSON, and no changes to the data in the API.
How to send data with a POST request
A POST request sends data to the API. It is commonly used to create a new record.
Example:
curl -X POST "https://api.example.com/customers" \
-H "Authorization: Bearer your_token_here" \
-H "Content-Type: application/json" \
-d '{
"name": "John Doe",
"email": "john.doe@example.com",
"plan": "premium"
}'
This request tells the API to create a new customer.
The API might return:
{
"id": 123,
"name": "John Doe",
"email": "john.doe@example.com",
"plan": "premium",
"created_at": "2026-05-09T10:30:00Z"
}
A successful POST request often returns 201 Created, the newly created record, and an ID generated by the system.
The most important header here is:
Content-Type: application/json
It tells the API that the request body is formatted as JSON. Without this header, some APIs will reject the request or fail to read the body correctly.
How REST API authentication works
Most real REST APIs require authentication. Authentication proves that you are allowed to access the API.
The three most common REST API authentication methods are API keys, bearer tokens, and Basic auth.
API key example
Some APIs use a custom header:
curl "https://api.example.com/orders" \
-H "x-api-key: your_api_key_here"
Others use a query parameter:
curl "https://api.example.com/orders?api_key=your_api_key_here"
Headers are usually safer and cleaner than putting keys directly in URLs.
Bearer token example
Bearer tokens are very common in modern APIs:
curl "https://api.example.com/orders" \
-H "Authorization: Bearer your_token_here"
The API checks the token and decides whether the request is allowed.
Basic auth example
Basic auth uses a username and password:
curl -u username:password "https://api.example.com/orders"
This is simple, but you should only use it over HTTPS.
How to read API documentation without getting lost
API documentation can feel overwhelming at first, but most docs follow the same basic structure.
When reading REST API documentation, look for these details first.
Example API documentation might say:
GET /orders
Base URL:
https://api.example.com
Full endpoint:
https://api.example.com/orders
Required header:
Authorization: Bearer token
Optional query parameters:
status=pending
limit=10
So your final request might look like this:
curl "https://api.example.com/orders?status=pending&limit=10" \
-H "Authorization: Bearer your_token_here"
The key is to build the request piece by piece. Start with the endpoint and method, then add authentication, then add filters or body data.
Common REST API errors and how to fix them
REST API errors usually come with HTTP status codes. These codes tell you what happened.
A 401 error usually means the API did not accept your credentials. Check that the token is correct, has not expired, and is formatted correctly in the Authorization header.
A 404 error usually means the endpoint or resource does not exist. Check the URL, resource ID, API version, and base URL.
A 429 error means you have hit the API’s rate limit. The fix is usually to send fewer requests, wait before retrying, or use pagination instead of requesting too much data at once.
curl vs Postman vs JavaScript fetch
You can call a REST API in many ways. The best tool depends on what you are trying to do.
curl example
curl "https://api.example.com/customers" \
-H "Authorization: Bearer your_token_here"
JavaScript fetch example
const response = await fetch("https://api.example.com/customers", {
method: "GET",
headers: {
"Authorization": "Bearer your_token_here",
"Accept": "application/json"
}
});
const data = await response.json();
console.log(data);
curl is often the clearest learning tool because it shows the request directly. Postman is easier when you want a visual interface. JavaScript fetch is useful when you are ready to use the API inside an application.
Real example: using a REST API in an internal tool
Imagine your support team needs a dashboard that shows customer tickets from an external helpdesk API.
The basic REST API flow might look like this:
- Send a GET request to fetch open tickets.
- Display the tickets in a table.
- Let a support manager review priority, customer, and status.
- Send a PATCH or POST request to update the ticket status.
- Log or display the updated result.
The first request might look like this:
curl "https://api.example.com/tickets?status=open" \
-H "Authorization: Bearer your_token_here"
The response might return:
[
{
"id": 1001,
"customer": "Acme Inc.",
"status": "open",
"priority": "high"
},
{
"id": 1002,
"customer": "BrightCo",
"status": "open",
"priority": "medium"
}
]
A developer could use this response in code. But for an internal operations team, raw JSON is not enough. They usually need a working interface with tables, filters, forms, buttons, permissions, and actions.
That is where an internal tool layer becomes useful.
How UI Bakery helps you work with REST APIs
Once your REST API request works, UI Bakery can help turn that API into an internal app for your team.
With UI Bakery, teams can connect to REST APIs through the HTTP API integration, configure authentication, and use API responses inside dashboards, admin panels, approval workflows, and internal tools.
For example, you can build:
- a support dashboard that pulls ticket data from an API
- an operations panel that updates order statuses through REST endpoints
- an approval workflow that reads and writes API data
- an internal admin tool over an existing backend
- a customer management interface connected to several APIs
UI Bakery is not the API itself and does not replace your backend. It acts as the application layer on top of your existing APIs, databases, and business systems.
A typical flow looks like this:
REST API request → UI Bakery app → internal user action → API update
For teams that already have REST endpoints but do not want to build every internal interface from scratch, this can be a practical middle ground. Developers keep control over the backend, while business and operations teams get usable tools for everyday work.
Build an internal tool on top of your REST API, or see how HTTP API connections work in UI Bakery.
REST API request example: full breakdown
Here is one full example request:
curl -X POST "https://api.example.com/orders" \
-H "Authorization: Bearer your_token_here" \
-H "Content-Type: application/json" \
-d '{
"customer_id": 123,
"product_id": 456,
"quantity": 2
}'
And here is what each part means.
A successful response might look like this:
{
"order_id": 789,
"customer_id": 123,
"product_id": 456,
"quantity": 2,
"status": "created"
}
This tells you the API received the request and created the order.
Beginner checklist for using a REST API
Before you assume the API is broken, check the basics:
- Are you using the correct endpoint URL?
- Are you using the correct HTTP method?
- Did you include the required authentication?
- Did you send the required headers?
- Is your JSON body valid?
- Are required fields missing?
- Are you using the correct API version?
- Did you check the status code and response body?
- Are you hitting a rate limit?
Most REST API problems come from small request details, not from the API concept itself.
Conclusion
Learning how to use a REST API starts with understanding the request: endpoint, method, headers, authentication, parameters, and body. Once you know how those parts fit together, you can call APIs with curl, test them in Postman, use them in JavaScript, or connect them to internal tools.
For beginners, the best path is simple: start with a GET request, confirm the response, add authentication, then move to POST or PATCH requests when you need to create or update data.
And once the API call works, the next question is often how your team will use that data in real workflows. That is where tools like UI Bakery can help you turn REST API data into dashboards, admin panels, forms, and approval flows for internal teams.
What do you need to use a REST API?
To use a REST API, you need an endpoint URL, an HTTP method, authentication credentials if required, request headers, and sometimes query parameters or a JSON body. You also need the API documentation so you know which endpoints and fields to use.
What is the easiest way to test a REST API?
The easiest way to test a REST API is usually with curl or Postman. curl is good for simple command-line examples, while Postman is easier if you prefer a visual interface for adding headers, authentication, and request bodies.
How do you authenticate to a REST API?
Most REST APIs use API keys, bearer tokens, or Basic auth. These credentials are usually sent in the request headers. A common example is Authorization: Bearer your_token_here.
What is the difference between GET and POST in a REST API?
GET is used to read data from a REST API. POST is used to send data to the API, usually to create a new record or trigger an action. GET requests usually do not have a body, while POST requests often send a JSON body.
Can you use a REST API without coding?
Yes, you can use a REST API without writing much code by using tools like Postman or internal app builders. For example, UI Bakery lets teams connect REST APIs to tables, forms, dashboards, and workflows so internal users can work with API data through a visual interface.
"The UI Bakery platform offers a cost-effective approach to creating applications. With UI Bakery, you can achieve your app development goals without breaking the bank."
"Before switching to UI Bakery we developed a number of apps within the Retool system. The Retool system was good but ultimately did not have the flexibility and feature sets that we required."
Check the Story