How to Get Data from the WordPress REST API (Endpoints + Examples)
Table of Contents
- Introduction
- What the WordPress REST API Is (And Where to Find It)
- Understanding WordPress REST API Endpoint Structure
- Most Useful Endpoints to Fetch Website Data
- How to Get Posts Using the REST API (Core Examples)
- WordPress REST API Fetch Example (JS) + Practical Output Handling
- Quick Examples in Other Formats (Curl + PHP)
- Common Issues When Fetching Data (And How to Fix Them)
- Best Practices for Safe, Fast REST API Data Fetching
- Conclusion
Introduction
WordPress is not only for blogs and simple pages. It can also power apps, tools, and custom websites. That is possible because WordPress can share data cleanly. It does this through the REST API system.
In this guide, you will learn simple REST API basics. You will also learn how WordPress shares content data. You will see where the API lives on your site. Then you can start to get data from WordPress REST API safely.
This topic matters for many USA business websites today. Teams want faster pages and flexible website layouts. Developers want clean data for apps and dashboards. Marketers want content shown in more places quickly.
Common real uses include these tasks below.
- Show latest posts inside a React or mobile app
- Pull pages into a headless front end setup
- Send content to tools like CRMs and email platforms
- Build custom search or filters for large content sites
What the WordPress REST API Is (And Where to Find It)
The WordPress REST API is a built-in WordPress feature. It lets you request site data using simple web links. The server returns the data in a JSON format. JSON is easy to read for apps and scripts.
You can fetch many types of public site content. This includes posts, pages, categories, tags, and media items. Most public data works without any login access. Private data may need special permission to access.
Where to find the REST API on your website
Every WordPress site has a base REST API address. It usually starts with the wp-json path. You can test it in seconds using a browser.
Use this base path format for quick testing:
https://yourdomain.com/wp-json/
Try these simple test methods for fast results.
- Open the link in Chrome, then view the JSON output
- Use Postman to send requests and view responses clearly
- Use a REST client browser extension for quick checks
If the link shows an error, do not panic. It can happen due to settings or security rules. We will cover fixes later in this guide. For now, you only need to confirm it loads.
Understanding WordPress REST API Endpoint Structure
To use the REST API, you must understand endpoint format. An endpoint is a URL path that returns specific data. WordPress builds these paths in a clear and predictable way.
Most WordPress REST API requests start with a base path. That base path is the same on almost every site. It looks like this format on your domain.
https://yourdomain.com/wp-json/
After that, you will see a namespace and a route. The namespace tells you which API group you use. The route tells you what data you want to fetch.
A common WordPress core namespace is this one.
/wp/v2/
So a full endpoint usually follows this simple pattern.
/wp-json/wp/v2/{route}
Here is an easy example you can remember.
https://yourdomain.com/wp-json/wp/v2/posts
This is why people often call them WordPress REST API endpoints. Each endpoint targets one data type and returns JSON.
How requests work in simple terms
A request is just a call to an endpoint URL. Your browser, app, or tool sends that request. WordPress replies with data in JSON format.
Most “read data” requests use the GET method. GET means you only want to view or pull data. You do not change anything on the website.
Other methods exist, but they are not needed yet.
- GET for reading data from the website
- POST for creating new items like posts
- PUT / PATCH for updating existing items
- DELETE for removing an item from the site
For this guide, we focus on GET requests only. That keeps things safe and beginner friendly.
What a successful response looks like
When an endpoint works, it returns a successful response. Tools show a status code for each response. The most common success code is 200.
You will also see a JSON output in the response body. It can be a list or a single item. A list is common when you fetch posts or pages.
Many tools show these response parts clearly.
- Status code like 200 or 404
- Response headers with extra details
- JSON body with the actual data
If you see JSON in the output, you are on track.
Most Useful Endpoints to Fetch Website Data
Now let’s cover the most used endpoints for real projects. These endpoints help you pull content and related data fast. You can test each one by opening it in a browser.
Posts endpoint for blog content
Posts are the most common data type in WordPress. You can fetch the latest blog posts with this endpoint.
- /wp-json/wp/v2/posts
This endpoint returns a list of post objects in JSON. Each object includes title, date, slug, and more fields.
Pages endpoint for static site pages
Pages are used for About, Contact, and landing pages. Use this endpoint to fetch published pages.
- /wp-json/wp/v2/pages
This is useful for headless websites and custom front ends.
Categories and tags for content grouping
Categories and tags help you build filters and menus. These endpoints return taxonomy data.
- /wp-json/wp/v2/categories
- /wp-json/wp/v2/tags
You can use these when building a topic based blog layout.
Media endpoint for images and files
WordPress stores uploads as media items. You can fetch image details using this endpoint.
- /wp-json/wp/v2/media
This helps when you want featured images in an app.
Comments endpoint for engagement data
If comments are enabled, you can fetch comment data too. This is helpful for community style blogs.
- /wp-json/wp/v2/comments
Some sites limit this for spam control and privacy needs.
Users endpoint and access limits
WordPress also has a users endpoint, but it is often locked. Many sites block it for safety reasons.
- /wp-json/wp/v2/users
Do not worry if it returns an error on your site. That is normal for many public websites.
Custom post type endpoints for custom content
Many sites use custom post types for special content. Examples include events, portfolios, or listings. WordPress often exposes them like this.
- /wp-json/wp/v2/{custom_post_type}
For example, a “services” post type may look like this.
- /wp-json/wp/v2/services
Once you know these endpoints, you can start pulling data.
How to Get Posts Using the REST API (Core Examples)
Most people start by pulling blog posts from WordPress. Posts are public on many sites by default. That makes them perfect for learning REST API basics.
To begin, you will use the posts endpoint on your site. The standard endpoint looks like this.
https://yourdomain.com/wp-json/wp/v2/posts
When you open it, WordPress returns a JSON list. Each item is one post with many fields. You will usually see the title, slug, date, and content data.
This is the most common way to WordPress REST API get posts quickly.
Example 1: Get the latest posts in one request
If you call the posts endpoint without filters, you get posts. WordPress sends the newest posts first by default. This is useful for blog feeds and home pages.
Use this endpoint for the latest posts.
- /wp-json/wp/v2/posts
If you want fewer posts, use the per_page parameter. It controls how many results you get in one call.
Example with a limit of five posts.
- /wp-json/wp/v2/posts?per_page=5
This reduces load and keeps responses fast.
Example 2: Pagination for “Load More” or page lists
Large blogs often have hundreds of posts. You should never load all posts at once. Instead, you load them page by page.
WordPress supports pagination using page and per_page.
- per_page sets how many posts per page
- page selects which page number you want
Example for page 2 with ten posts per page.
- /wp-json/wp/v2/posts?per_page=10&page=2
If you go too far, you may see an error. That often means the page does not exist.
Many API tools also show pagination headers. These headers tell you how many pages exist. They help you build better “Next” and “Previous” buttons.
Example 3: Search posts by keyword
Sometimes you want posts matching a search term. WordPress supports this with the search parameter.
Example to search posts for “hosting” topics.
- /wp-json/wp/v2/posts?search=hosting
This returns posts where the term matches title or content. It is useful for custom site search features.
Example 4: Get a specific post using the slug
A slug is the URL friendly post name. It is often stable and easy to use. You can fetch a post by slug using the slug filter.
Example to fetch one post by slug.
- /wp-json/wp/v2/posts?slug=example-post
This returns an array, even for one post. That is normal for this endpoint.
If you want one clean item, you can take the first object. Your app can do that in a simple way.
Example 5: Filter posts by category or tag
Categories and tags help you create topic pages. WordPress lets you filter posts by category ID. It also supports tag filtering using tag IDs.
Category filter example using category ID 12.
- /wp-json/wp/v2/posts?categories=12
Tag filter example using tag ID 8.
- /wp-json/wp/v2/posts?tags=8
This is perfect for “News”, “Guides”, or “Fixes” sections.
Example 6: Sort posts by date or title
You can change sorting using orderby and order. This helps when building custom lists or archives.
Common orderby values include date and title.
- /wp-json/wp/v2/posts?orderby=date&order=desc
- /wp-json/wp/v2/posts?orderby=title&order=asc
Use sorting carefully on very large sites. Sorting can increase server load for some setups.
Make responses smaller using _fields
REST API responses can be large and heavy. If you only need a few fields, limit output. WordPress supports _fields to reduce response size.
Example for only ID, title, and link.
- /wp-json/wp/v2/posts?_fields=id,title,link
This makes your page faster and saves bandwidth too.
Use _embed to include featured image and author
Many apps want featured images and author info. Without embedding, you need extra requests. _embed can include related objects in one response.
Example with embedding enabled.
- /wp-json/wp/v2/posts?_embed
This is helpful for blog cards and post listing layouts.
WordPress REST API Fetch Example (JS) + Practical Output Handling
Once you know the endpoint, you can fetch data fast. JavaScript is a common choice for modern websites. It works well for headless sites and simple widgets.
In this section, you will see a clean WordPress REST API fetch example. You will also learn how to handle the output safely. The goal is simple and practical for real use.
How the fetch flow works in real projects
Most REST API fetch work follows the same pattern. You build the endpoint URL first. Then you send a request and read JSON data. After that, you display the output in your UI.
Here is the basic flow you will repeat often.
- Build the endpoint URL with your filters
- Call fetch() with that URL
- Check if the response is successful
- Convert the response to JSON
- Loop through items and display the data
Example 1: Fetch latest posts and list titles
This example gets the newest posts and shows titles. It also limits results for faster loading. Replace yourdomain.com with your real domain.
async function getLatestPosts() {
const url = “https://yourdomain.com/wp-json/wp/v2/posts?per_page=5&_fields=id,title,link”;
const res = await fetch(url);
if (!res.ok) {
throw new Error(“Request failed with status ” + res.status);
}
const posts = await res.json();
return posts.map(post => ({
id: post.id,
title: post.title.rendered,
link: post.link
}));
}
This returns a clean list of post data you can show. You can print it in console or render it on a page.
If you want a simple output list, use this idea.
- Show the title as a clickable link
- Keep the list short for better user experience
- Load more posts only when needed
Example 2: Fetch a single post using the slug
Many apps use the slug to load a post page. This keeps URLs stable and easy to manage. The REST API supports slug filtering directly.
async function getPostBySlug(slug) {
const url = `https://yourdomain.com/wp-json/wp/v2/posts?slug=${encodeURIComponent(slug)}&_fields=id,title,content,link`;
const res = await fetch(url);
if (!res.ok) {
throw new Error(“Request failed with status ” + res.status);
}
const data = await res.json();
return data.length ? data[0] : null;
}
Because the response is an array, you pick the first item. If the array is empty, the post does not exist.
You can handle that case like this.
- Show a “Post not found” message
- Offer a link back to the blog page
- Log the missing slug for debugging
Example 3: Fetch posts by category for topic pages
Category pages are common for blogs and support sites. You can build custom category pages using category IDs. This example loads posts from one category.
async function getPostsByCategory(categoryId) {
const url = `https://yourdomain.com/wp-json/wp/v2/posts?categories=${categoryId}&per_page=10&_fields=id,title,link`;
const res = await fetch(url);
if (!res.ok) {
throw new Error(“Request failed with status ” + res.status);
}
return await res.json();
}
This is useful when you build pages like “Fixes” or “Guides”. It also helps for a knowledge base style layout.
Basic error handling that keeps users happy
Errors are normal in real websites and apps. Your job is to fail safely and show a friendly message. Always check res.ok before reading JSON.
Use these simple rules for cleaner handling.
- Show a short error message to users
- Keep technical details only in console logs
- Retry only when it makes real sense
A common user friendly message can be this.
- “We could not load posts right now. Please try again.”
Quick note about cross domain requests
If your app runs on a different domain, requests may fail. That happens due to browser security rules. Many teams solve it using server side calls or allowed origins. You do not need to fix it now. Just remember it when building a separate front end.
Quick Examples in Other Formats (Curl + PHP)
Not everyone wants JavaScript for API testing and use. Many developers prefer quick terminal tests or server side calls. Curl and PHP make that easy.
Curl example for fast endpoint testing
Curl is great for quick checks and debugging. You can test the posts endpoint in seconds.
curl “https://yourdomain.com/wp-json/wp/v2/posts?per_page=3”
If the endpoint works, you will see JSON in the output. If it fails, you will see an error response.
Curl is best when you want these tasks.
- Confirm an endpoint works before writing code
- Test filters like search or slug quickly
- Compare response sizes with and without _fields
PHP example using wp_remote_get inside WordPress
If you want server side fetching in WordPress, use wp_remote_get(). This method is safe and works well with WordPress hosting setups.
$response = wp_remote_get(‘https://yourdomain.com/wp-json/wp/v2/posts?per_page=5’);
if (is_wp_error($response)) {
return [];
}
$body = wp_remote_retrieve_body($response);
$posts = json_decode($body, true);
This is useful for these use cases.
- Show REST API data inside a WordPress template
- Connect two WordPress sites and share content
- Fetch data without browser limits like CORS
Common Issues When Fetching Data (And How to Fix Them)
REST API requests are simple, but issues can still happen. Most problems come from settings, permissions, or blocked requests. The good news is fixes are usually quick.
Issue 1: Endpoint shows 404 or returns a blank page
A 404 error means the endpoint route is not found. This often happens when permalinks are not set right. It can also happen after a migration or URL change.
Try these fixes in order.
- Go to Settings > Permalinks in WordPress admin.
- Click Save Changes without changing anything.
- Clear your site cache and CDN cache if active.
- Test the endpoint again using the base /wp-json/ path.
If it still fails, check if .htaccess rules are missing. On Nginx, check rewrite rules in the server config.
Issue 2: You get 401 or 403 access denied errors
These errors mean access is blocked by permissions. Public posts usually load without login access. Private posts, drafts, and users data often need auth.
Common reasons for blocked access include these.
- You are trying to fetch private content without login
- A security plugin blocks REST calls for safety
- Hosting firewall blocks repeated API requests
- The endpoint needs an API key or token
Fix steps you can try safely.
- Test a public endpoint like /wp/v2/posts first
- Disable REST API blocks inside security plugin settings
- Whitelist your IP if the firewall is blocking requests
- Use proper auth only when private data is required
Issue 3: You get fewer results than expected
Sometimes you expect many posts but get only a few. This is often caused by pagination defaults and request limits. WordPress has built-in limits for safety.
Here is what to check first.
- Add per_page=10 or per_page=20 in your endpoint
- Use page=2 or higher to fetch older posts
- Confirm posts are published and not set to private
- Check category or tag IDs used in filters
Also remember that per_page has a max limit. Many sites cap it at 100 for safety. If you need more, use pagination instead.
Issue 4: Your site feels slow when fetching data
Speed issues happen when responses are too large. Posts can include content, images, and embedded data. That can increase load and slow pages.
Use these quick speed fixes.
- Use _fields to return only needed fields
- Use per_page to limit the number of posts
- Avoid loading full content in listing pages
- Cache results on your server or app layer
If you need featured images, use _embed carefully. It is helpful, but it adds more data in one response.
Best Practices for Safe, Fast REST API Data Fetching
If you want stable results, follow a few best rules. These rules help both performance and safety. They also reduce errors on busy websites.
Keep your responses small and focused
Never request more data than you need. Smaller responses load faster for USA users on mobile networks. Use _fields for clean output in most cases.
A good listing request can look like this.
- /wp-json/wp/v2/posts?per_page=5&_fields=id,title,link,date
This keeps pages fast and improves user experience.
Cache results for better speed and stability
If your content does not change every minute, cache it. You can cache it in your app, server, or CDN. This reduces repeat calls and helps avoid rate limits.
Caching works well for these cases.
- Latest posts list on homepage
- Category pages with fixed post lists
- Navigation menus built from categories
Avoid exposing private data by mistake
Public endpoints are fine for public posts and pages. But private data must stay protected. Never expose private posts, users data, or admin info publicly.
If you need private content access, use safe auth methods. Many WordPress sites use Application Passwords for simple API access. You can also use cookie auth for same domain use.
Use the right tool for the right job
Front end fetch is great for widgets and headless sites. Server side calls are better for secure or heavy work. Pick what fits your use case best.
A simple guide can be this.
- JS fetch for public data and simple UI parts
- PHP server calls for secure data and better control
- Curl for quick tests and fast debugging
Conclusion
Now you know how to read WordPress data using REST API. You learned endpoint structure, filters, and simple fetch methods. You can now get data from WordPress REST API in a clean way. You also learned common fixes and best practices for speed.
If you want help building secure API features, we can help. WooHelpDesk can help you connect endpoints, fix REST errors, and improve speed. Reach out to WooHelpDesk when you want expert WordPress support.

