The WordPress REST API represents a fundamental shift in how developers interact with WordPress, transforming it from a traditional monolithic CMS into a flexible, API-first content management platform. By exposing WordPress data through standardized REST endpoints, this built-in feature--available since WordPress 4.7--enables seamless integration with external applications, single-page applications built with React or Next.js, mobile applications, and entirely decoupled frontends. Whether you're building a React Native mobile application that delivers your blog content, creating a custom admin dashboard for clients, or integrating WordPress into a modern JavaScript framework ecosystem, the REST API provides the programmatic interface needed to remotely control virtually every aspect of your WordPress installation.
For development teams working with Next.js and modern frontend frameworks, the WordPress REST API serves as the bridge between WordPress's intuitive content management experience and the performance benefits of server-side rendering, static generation, and edge computing. Our /services/web-development team specializes in building these hybrid architectures that combine the best of traditional CMS usability with modern frontend performance.
What Is the WordPress REST API
The WordPress REST API is an interface that allows developers to interact with WordPress sites programmatically using standard HTTP requests. Rather than relying solely on PHP templates and the WordPress theme system, developers can now access WordPress data--posts, pages, users, media, categories, tags, and custom post types--through JSON-formatted endpoints that follow REST (Representational State Transfer) architectural principles. This architectural approach means you can read, create, update, and delete content on your WordPress site using virtually any programming language or HTTP client, from JavaScript running in a browser to Python scripts on a server to Swift or Kotlin code in native mobile applications.
The significance of this capability cannot be overstated for modern web development workflows. Teams can now leverage WordPress as a content repository while building completely custom frontends using Next.js, Gatsby, Vue, or any other framework that can consume JSON data. This separation of concerns enables frontend teams to work independently using their preferred tools and methodologies while content editors continue using the WordPress admin interface they already know. The result is a more flexible development process, better performance through optimized frontend rendering strategies, and the ability to deliver content across multiple platforms from a single content source.
REST API Fundamentals and HTTP Methods
REST (Representational State Transfer) is an architectural style for designing networked applications that has become the standard for modern web APIs. In the context of WordPress, the REST API implements this architecture by providing endpoints that follow standard HTTP methods, each corresponding to a specific operation on your WordPress data. Understanding these methods is essential for effective API integration.
GET requests retrieve data from the server without modifying anything. When you access /wp-json/wp/v2/posts, you're sending a GET request to fetch a list of posts. GET requests are idempotent and safe, meaning they can be cached by browsers and CDNs and will never modify server state.
POST requests create new resources on the server. Sending a POST request to /wp-json/wp/v2/posts with a JSON body containing title and content will create a new draft post in your WordPress database. POST requests require authentication when creating or modifying content.
PUT and PATCH requests update existing resources, with subtle differences in their semantics. PUT requests typically replace an entire resource with the provided data, while PATCH requests modify only the specified fields. Both require authentication and are commonly used for updating post content, changing post status, or modifying user profiles.
DELETE requests remove resources from the server. Sending a DELETE request to /wp-json/wp/v2/posts/123 will permanently remove that post from your WordPress database. As with modification operations, DELETE requests require appropriate authentication and permissions.
WordPress REST API Architecture
The WordPress REST API is built directly into WordPress core, meaning you don't need to install any plugins to use it on modern WordPress installations running version 4.7 or higher. The API follows a hierarchical URL structure that makes endpoints predictable and easy to discover. The base URL pattern follows the format yoursite.com/wp-json/wp/v2/, with additional path segments identifying specific resources and operations.
For example, accessing /wp-json/wp/v2/posts retrieves a list of all published posts with full metadata, while /wp-json/wp/v2/posts/123 retrieves the specific post with ID 123. This predictable structure extends to all WordPress resources: /wp-json/wp/v2/pages for pages, /wp-json/wp/v2/media for the media library, /wp-json/wp/v2/users for user data, and /wp-json/wp/v2/comments for comments. Each endpoint supports the same set of HTTP methods for CRUD operations, making the API consistent and intuitive to work with across different resource types.
The API returns data in JSON format, which has become the universal standard for API data interchange because it's both human-readable and easy to parse in any programming language. Response objects include all relevant fields for the requested resource--titles, content, dates, author information, featured images, metadata, and embedded related resources--formatted as structured JSON that integrates naturally with modern JavaScript frameworks and their component-based architectures.
As documented in the WordPress REST API Handbook, this architecture enables developers to build sophisticated applications that leverage WordPress as a content backend while maintaining complete freedom over the presentation layer.
Core Endpoints and Capabilities
The WordPress REST API exposes a comprehensive set of endpoints that cover virtually every aspect of WordPress content management. Understanding these endpoints is essential for effectively leveraging the API's capabilities in your applications. Each endpoint supports specific operations and accepts various parameters that allow you to filter, sort, paginate, and customize the returned data. The API is designed to be both powerful for advanced use cases and accessible for beginners, with sensible defaults that make simple tasks straightforward while still providing the flexibility needed for complex integrations.
Posts Endpoint
The posts endpoint (/wp/v2/posts) is one of the most frequently used endpoints in the WordPress REST API, providing full CRUD (Create, Read, Update, Delete) capabilities for WordPress posts including custom post types. When you make a GET request to this endpoint, you can retrieve lists of posts with powerful filtering options including status (draft, published, pending, private, trash), author ID, category and tag slugs or IDs, date ranges, and full-text search terms. Each post object returned includes all standard WordPress post data--title, content, excerpt, date, featured image, meta fields, and more--formatted as clean JSON that integrates easily with React components, Vue templates, or any other frontend rendering system.
For Next.js applications, the posts endpoint serves as the foundation for dynamic content strategies. You can fetch posts at build time for static site generation (using getStaticProps or generateStaticParams), at request time for server-side rendering (using getServerSideProps or dynamic API routes), or incrementally for hybrid approaches using Incremental Static Regeneration. The endpoint's support for the _embed parameter is particularly valuable, as it automatically includes related resources like featured images, authors, and taxonomy terms in the response, reducing the number of API calls needed to populate a complete post view.
Pages, Media, and Users Endpoints
Beyond posts, the REST API provides dedicated endpoints for all major WordPress content types, each following the same consistent pattern for URL structure and operation methods. The pages endpoint (/wp/v2/pages) works identically to posts but is optimized for hierarchical page content, respecting WordPress's page nesting structure and parent-child relationships. This is essential for building navigation systems, table of contents, and breadcrumb trails in headless applications.
The media endpoint (/wp/v2/media) is particularly valuable for applications that need to manage the media library programmatically, allowing uploads directly through the API without requiring access to the WordPress admin interface. This capability enables workflows where images are uploaded from external sources, user-generated content is processed and stored, or automated systems manage large media collections. Media objects include detailed metadata--alt text, captions, dimensions, file sizes, and MIME types--making it easy to build responsive image components that serve appropriately sized versions for different devices.
The users endpoint (/wp/v2/users) provides access to user data with appropriate permission checks to protect sensitive information. For public data, basic user information like ID, name, URL, and description is available without authentication. For operations that access or modify private user data, proper authentication is required, and the API respects WordPress's role-based capability system to ensure users can only access data they're authorized to see.
According to the Hostinger WordPress REST API tutorial, these core endpoints form the foundation for most headless WordPress implementations, providing all the functionality needed to build sophisticated content-driven applications.
Authentication Methods
Authentication is a critical aspect of the WordPress REST API, determining who can access which endpoints and what operations they can perform. WordPress provides multiple authentication mechanisms, each suited to different use cases and security requirements. For public data that should be accessible to anyone--such as reading published posts, pages, categories, and tags--the API supports non-authenticated requests that have read-only access to public content. For operations that modify content or access protected data, you must implement proper authentication to verify the requester's identity and permissions. Understanding these authentication methods is essential for building secure integrations that protect your WordPress site while enabling the functionality your application needs.
Non-Authenticated Access
Non-authenticated requests to the WordPress REST API are limited to read-only operations on public content. This means any visitor can retrieve published posts, pages, categories, tags, and other public content without providing any credentials. This open-by-default approach aligns with the fundamental principle of the web that publicly accessible content should be easily retrievable through standard protocols. For many use cases--particularly content display applications--this is exactly what you need. A JavaScript application running in a user's browser can fetch and display WordPress content without any authentication concerns, as the content is intended to be public anyway.
This behavior has important implications for security planning. While read-only public access is the default for most endpoints, you should audit which endpoints are exposed and consider using the rest_authentication_errors filter to restrict access if your use case requires it. Additionally, the users endpoint has special handling that prevents non-authenticated access to user lists while still allowing individual user objects to be accessed when their ID is known, protecting against enumeration attacks that could reveal information about your site's user accounts.
Application Passwords
Application Passwords represent one of the most straightforward authentication methods for the WordPress REST API, introduced in WordPress 5.6 to simplify the process of creating secure integrations. This feature generates unique passwords tied to specific applications or use cases, allowing you to revoke access for individual applications without affecting other integrations or the user's main WordPress password. This granular control is invaluable for managing multiple integrations--whether you're building a mobile app, a desktop application, or connecting to an external service--because compromised credentials can be revoked without disrupting other systems.
To use Application Passwords, you generate credentials through the WordPress admin interface by navigating to Users → Profile → Application Passwords section. There you can create a new application password with a descriptive name (like "Mobile App" or "Next.js Frontend"), and WordPress will generate a unique password that can be used for API authentication. This password is used alongside the username in HTTP Basic Authentication, where the credentials are encoded in the Authorization header. For production applications, ensure all API calls are made over HTTPS to prevent credential interception, as Basic Auth transmits credentials in base64 encoding which can be easily decoded if intercepted.
OAuth and JWT Authentication
For production applications, particularly those serving multiple users or deployed at scale, OAuth 2.0 and JWT (JSON Web Token) authentication provide more robust security frameworks than Application Passwords. OAuth 2.0 is an industry-standard authorization protocol that allows applications to obtain limited access to user accounts without exposing the user's main WordPress password. This is essential for applications where users need to authorize third-party access to their data--such as a mobile app that posts to a user's blog or a dashboard that manages multiple WordPress sites.
JWT (JSON Web Token) provides a compact, URL-safe method for transmitting claims between parties, typically used in conjunction with authentication plugins that extend the REST API with JWT support. When a user authenticates, the server issues a signed token that contains encoded claims about the user's identity and permissions. This token can be verified by any party with the public key, allowing stateless authentication that scales well for distributed systems. As outlined in Jetpack's REST API resources, while OAuth and JWT require more initial setup and often benefit from existing libraries or plugins, they offer significant advantages in terms of security, scalability, and user experience for multi-user applications.
Practical Implementation Examples
Understanding authentication and endpoints is only part of the equation--actually implementing the WordPress REST API in your applications requires practical knowledge of how to construct requests, handle responses, and manage common scenarios. The following examples demonstrate real-world patterns for reading content, creating and updating posts, and handling authentication in various programming contexts. These patterns form the foundation for building any integration with WordPress, whether you're creating a simple content display component or a full-featured headless application.
Reading Posts with JavaScript
The most common starting point for WordPress REST API integration is reading and displaying posts in a JavaScript application. Modern JavaScript frameworks like React, Vue, and Angular make it straightforward to fetch data from APIs and render it in components. Using the built-in Fetch API or libraries like Axios, you can retrieve posts from your WordPress site and display them without any authentication required--for public posts. The response includes comprehensive post data that can be mapped directly to your component state, enabling reactive updates when content changes on the WordPress site.
1// Fetch posts from WordPress REST API2async function fetchPosts(options = {}) {3 const { perPage = 10, page = 1, category = null, search = '' } = options;4 5 let url = `https://your-wordpress-site.com/wp-json/wp/v2/posts?_embed&per_page=${perPage}&page=${page}`;6 7 if (category) {8 url += `&categories=${category}`;9 }10 11 if (search) {12 url += `&search=${encodeURIComponent(search)}`;13 }14 15 const response = await fetch(url, {16 headers: {17 'Accept': 'application/json'18 }19 });20 21 if (!response.ok) {22 throw new Error(`HTTP error! status: ${response.status}`);23 }24 25 const posts = await response.json();26 const totalPages = parseInt(response.headers.get('X-WP-TotalPages') || '1');27 const totalPosts = parseInt(response.headers.get('X-WP-Total') || '0');28 29 return {30 posts: posts.map(normalizePost),31 pagination: {32 totalPages,33 totalPosts,34 currentPage: page35 }36 };37}38 39// Normalize post data for consistent frontend consumption40function normalizePost(post) {41 return {42 id: post.id,43 title: post.title.rendered,44 excerpt: post.excerpt.rendered,45 content: post.content.rendered,46 date: post.date,47 slug: post.slug,48 status: post.status,49 author: post._embedded?.['author']?.[0]?.name || 'Unknown',50 featuredImage: post._embedded?.['wp:featuredmedia']?.[0]?.source_url || null,51 categories: post._embedded?.['wp:term']?.[0]?.map(cat => ({52 id: cat.id,53 name: cat.name,54 slug: cat.slug55 })) || [],56 tags: post._embedded?.['wp:term']?.[1]?.map(tag => ({57 id: tag.id,58 name: tag.name,59 slug: tag.slug60 })) || []61 };62}63 64// Usage with React65async function BlogPosts({ category, limit = 6 }) {66 try {67 const { posts } = await fetchPosts({ perPage: limit, category });68 69 return (70 <div className="blog-grid">71 {posts.map(post => (72 <article key={post.id} className="blog-card">73 {post.featuredImage && (74 <img src={post.featuredImage} alt={post.title} />75 )}76 <h2>{post.title}</h2>77 <div dangerouslySetInnerHTML={{ __html: post.excerpt }} />78 </article>79 ))}80 </div>81 );82 } catch (error) {83 return <p>Error loading posts: {error.message}</p>;84 }85}This implementation demonstrates several important patterns for professional API integration. The _embed parameter in the URL tells WordPress to automatically include related resources in the response--featured images, author data, and taxonomy terms--which would otherwise require additional API calls. The X-WP-TotalPages and X-WP-Total headers in the response provide pagination information that's essential for building pagination controls and infinite scroll functionality.
The normalizePost function is a critical pattern for production applications. By extracting and transforming the raw WordPress response into a consistent internal format, you create an abstraction layer that isolates your frontend components from changes in the WordPress API structure. This normalization also removes the HTML-wrapped fields (using the rendered properties) and provides a cleaner data structure for your components to work with.
Creating Posts Programmatically
Creating content through the REST API opens possibilities for automated publishing workflows, external content management systems, and custom authoring tools. To create a post, you send a POST request to the posts endpoint with JSON data containing the post title, content, and any other desired fields. The request must include appropriate authentication headers, typically using Application Passwords for simpler integrations or OAuth for production multi-user applications. The API validates the data, creates the post with the specified status, and returns the created post object with its new ID.
1"""2Create WordPress posts programmatically using Python3Requires: pip install requests4"""5import requests6from requests.auth import HTTPBasicAuth7import json8 9class WordPressClient:10 def __init__(self, site_url, username, application_password):11 self.site_url = site_url.rstrip('/')12 self.api_base = f"{self.site_url}/wp-json/wp/v2"13 self.auth = HTTPBasicAuth(username, application_password)14 self.headers = {15 'Content-Type': 'application/json',16 'Accept': 'application/json'17 }18 19 def create_post(self, title, content, status='draft', featured_media=None,20 categories=None, tags=None, meta=None):21 """Create a new post with the specified content."""22 post_data = {23 'title': title,24 'content': content,25 'status': status,26 'featured_media': featured_media27 }28 29 if categories:30 post_data['categories'] = categories if isinstance(categories, list) else [categories]31 if tags:32 post_data['tags'] = tags if isinstance(tags, list) else [tags]33 if meta:34 post_data['meta'] = meta35 36 response = requests.post(37 f"{self.api_base}/posts",38 auth=self.auth,39 json=post_data,40 headers=self.headers41 )42 43 if response.status_code in (200, 201):44 return response.json()45 else:46 raise Exception(f"Failed to create post: {response.status_code} - {response.text}")47 48 def update_post(self, post_id, **kwargs):49 """Update an existing post with new content."""50 response = requests.put(51 f"{self.api_base}/posts/{post_id}",52 auth=self.auth,53 json=kwargs,54 headers=self.headers55 )56 57 if response.ok:58 return response.json()59 else:60 raise Exception(f"Failed to update post: {response.status_code}")61 62 def delete_post(self, post_id, force=False):63 """Delete a post. Set force=True to bypass trash."""64 response = requests.delete(65 f"{self.api_base}/posts/{post_id}",66 auth=self.auth,67 params={'force': force},68 headers=self.headers69 )70 71 if response.ok:72 return response.json()73 else:74 raise Exception(f"Failed to delete post: {response.status_code}")75 76 77# Example usage78if __name__ == "__main__":79 wp = WordPressClient(80 site_url="https://your-wordpress-site.com",81 username="admin",82 application_password="xxxx xxxx xxxx xxxx xxxx xxxx"83 )84 85 # Create a new post86 new_post = wp.create_post(87 title="New Post via REST API",88 content="""<p>This post was created programmatically using Python.</p>89 <p>The WordPress REST API enables powerful automation workflows.</p>""",90 status="draft",91 categories=[15, 22], # Category IDs92 tags=[5, 12] # Tag IDs93 )94 95 print(f"Created post ID: {new_post['id']}")96 print(f"Post link: {new_post['link']}")This Python implementation demonstrates a production-ready client for managing WordPress content programmatically. The class-based structure encapsulates authentication, headers, and error handling, making it reusable across different parts of your application. The create_post method accepts all common post fields and handles the conversion of single values to lists where appropriate (like categories and tags).
For Next.js applications, similar patterns can be implemented using API routes that run server-side with Application Passwords stored in environment variables. This keeps sensitive credentials out of client-side code while still enabling automated content publishing workflows, content migration scripts, and integration with external content sources. As shown in the ThriveWP REST API tutorial, this approach enables powerful automation scenarios that streamline content management operations. By leveraging our /services/ai-automation expertise, you can build sophisticated automation pipelines that connect WordPress with external data sources, content syndication networks, and enterprise systems.
Headless WordPress Architecture
Headless WordPress represents a paradigm shift in how we think about WordPress websites. Rather than using WordPress themes to both manage content and display it, a headless architecture separates these concerns: WordPress serves purely as a content management backend through the REST API, while a separate frontend application--built with Next.js, React, Vue, or another framework--handles the presentation layer. This separation offers significant advantages in terms of performance, security, and development flexibility, enabling teams to leverage modern frontend technologies while still benefiting from WordPress's intuitive content management interface that content editors already know.
Benefits of Headless Architecture
The headless approach transforms WordPress from a monolithic CMS into a content backend that can power multiple frontends simultaneously. Your content in WordPress can reach users through a traditional website, a mobile application, a smart TV app, digital signage displays, and any other platform that can consume JSON data--all without duplicating content or maintaining separate publishing workflows. This multi-platform publishing capability is particularly valuable for content publishers, news organizations, and businesses that need to maintain a consistent presence across diverse channels.
Performance improves significantly because the frontend can be optimized independently using strategies like static site generation, server-side rendering, or edge caching. Next.js applications can pre-render pages at build time, serving static HTML that loads instantly while hydrating into interactive React components on the client. This approach eliminates the database queries and PHP processing that would be required for each page view in a traditional WordPress theme, resulting in dramatically faster load times and better Core Web Vitals scores. Implementing headless architecture through our /services/web-development services delivers these performance gains while maintaining the content management workflow your team prefers.
Security also improves in headless architectures since the WordPress installation can be placed behind additional layers of protection. With the API-only interface exposed, the WordPress admin, theme files, and plugin vulnerabilities are no longer directly accessible from the frontend. The attack surface is significantly reduced, and you can implement additional security measures like API rate limiting, IP-based restrictions, and webhook authentication without affecting the user-facing website.
Building with Next.js and WordPress
Next.js has emerged as a particularly popular frontend choice for headless WordPress implementations, combining server-side rendering, static site generation, and API routes in a unified framework. When combined with the WordPress REST API, Next.js enables hybrid approaches where some pages are statically generated at build time for maximum performance while others are server-rendered for dynamic content or client-rendered for interactive components. This flexibility allows you to optimize each page's rendering strategy based on its content patterns and user experience requirements.
1/**2 * Next.js App Router: Dynamic blog post page3 * Uses Incremental Static Regeneration for optimal performance4 */5 6import { notFound } from 'next/navigation';7import { getPostBySlug, getAllPostSlugs } from '@/lib/wordpress';8import { PostCard } from '@/components/PostCard';9 10export const revalidate = 3600; // ISR: Regenerate every hour11 12export async function generateStaticParams() {13 const slugs = await getAllPostSlugs();14 return slugs.map(slug => ({ slug }));15}16 17export async function generateMetadata({ params }) {18 const post = await getPostBySlug(params.slug);19 20 if (!post) return {};21 22 return {23 title: post.title,24 description: post.excerpt.stripTags(),25 openGraph: {26 title: post.title,27 description: post.excerpt.stripTags(),28 images: post.featuredImage ? [post.featuredImage] : [],29 type: 'article',30 publishedTime: post.date,31 authors: [post.author]32 }33 };34}35 36export default async function BlogPostPage({ params }) {37 const post = await getPostBySlug(params.slug);38 39 if (!post) {40 notFound();41 }42 43 return (44 <article className="max-w-4xl mx-auto px-4 py-12">45 <header className="mb-8">46 <h1 className="text-4xl font-bold mb-4">{post.title}</h1>47 <div className="flex items-center gap-4 text-gray-600">48 <span>By {post.author}</span>49 <time dateTime={post.date}>50 {new Date(post.date).toLocaleDateString('en-US', {51 year: 'numeric',52 month: 'long',53 day: 'numeric'54 })}55 </time>56 </div>57 </header>58 59 {post.featuredImage && (60 <figure className="mb-8">61 <img 62 src={post.featuredImage} 63 alt={post.title}64 className="w-full h-auto rounded-lg"65 loading="eager"66 />67 </figure>68 )}69 70 <div 71 className="prose prose-lg max-w-none"72 dangerouslySetInnerHTML={{ __html: post.content }}73 />74 75 {post.categories.length > 0 && (76 <footer className="mt-12 pt-8 border-t">77 <div className="flex gap-2">78 {post.categories.map(cat => (79 <span key={cat.id} className="px-3 py-1 bg-blue-100 text-blue-800 rounded-full text-sm">80 {cat.name}81 </span>82 ))}83 </div>84 </footer>85 )}86 </article>87 );88}This Next.js implementation showcases several key patterns for professional headless WordPress sites. The revalidate = 3600 export enables Incremental Static Regeneration (ISR), which means Next.js will serve a statically generated page while regenerating it in the background when requests come in after the hour has elapsed. This provides the performance of static generation with the freshness of dynamic content.
The generateStaticParams function pre-renders all blog posts at build time, ensuring instant page loads for known content. For sites with thousands of posts, you can modify this pattern to pre-render only the most popular posts while generating others on-demand. The generateMetadata function enables full SEO optimization, dynamically generating meta tags, Open Graph data, and structured data from the WordPress content. Integrating with our /services/seo-services ensures your headless WordPress site achieves maximum search visibility while maintaining the performance benefits of static generation.
Security Best Practices
Securing your WordPress REST API endpoints is paramount when exposing programmatic access to your site. While the API enables powerful integrations, each exposed endpoint represents a potential attack vector if not properly protected. Implementing comprehensive security measures protects both your WordPress installation and the applications that depend on it. The following practices form the foundation of a secure REST API implementation, addressing authentication, authorization, input validation, rate limiting, and monitoring concerns that every responsible developer should consider.
Implementing Rate Limiting
Rate limiting prevents abuse by restricting how many requests a client can make within a specified time window. Without rate limiting, malicious actors or misbehaving applications could overwhelm your server with API requests, causing denial of service for legitimate users. The WordPress REST API includes built-in rate limiting that tracks requests by IP address, returning headers that indicate remaining request quota. For production deployments, implement additional rate limiting at the server level (Nginx, Apache) or through a CDN like Cloudflare to provide more granular control and protection against sophisticated distributed attacks.
According to Jetpack's security recommendations, rate limiting should be configured with appropriate thresholds based on your expected traffic patterns. Public read endpoints may allow higher limits since they're typically cached, while write endpoints should have stricter limits to prevent brute force attacks or automated content spam.
1<?php2/**3 * Add custom rate limiting to WordPress REST API4 * Add to theme's functions.php or custom plugin5 */6 7// Customize the REST API rate limit headers8add_filter('rest_post_dispatch', function($response, $server, $request) {9 // Get the current request count from transient10 $ip = $_SERVER['REMOTE_ADDR'];11 $transient_key = 'rest_rl_' . md5($ip);12 $request_count = get_transient($transient_key) ?: 0;13 14 // Increment and store15 $request_count++;16 set_transient($transient_key, $request_count, MINUTE_IN_SECONDS);17 18 // Add rate limit headers19 $response->header('X-RateLimit-Limit', 100);20 $response->header('X-RateLimit-Remaining', max(0, 100 - $request_count));21 $response->header('X-RateLimit-Reset', time() + (MINUTE_IN_SECONDS - (time() % MINUTE_IN_SECONDS)));22 23 return $response;24}, 10, 3);25 26// Block excessive requests27add_action('rest_api_init', function() {28 register_rest_route('custom/v1', '/security/check', [29 'methods' => 'GET',30 'callback' => 'check_security_status',31 'permission_callback' => function() {32 $ip = $_SERVER['REMOTE_ADDR'];33 $transient_key = 'rest_rl_' . md5($ip);34 $request_count = get_transient($transient_key) ?: 0;35 36 // Block if more than 100 requests per minute37 if ($request_count > 100) {38 return new WP_Error(39 'rate_limit_exceeded',40 'Too many requests. Please try again later.',41 ['status' => 429]42 );43 }44 45 return true;46 }47 ]);48});49 50function check_security_status($request) {51 return rest_ensure_response([52 'status' => 'secure',53 'timestamp' => current_time('mysql'),54 'version' => get_bloginfo('version')55 ]);56}Input Validation and Sanitization
All data received through the REST API must be treated as potentially malicious and subjected to rigorous validation and sanitization before processing. WordPress core provides extensive sanitization functions--sanitize_text_field(), sanitize_email(), esc_url(), and many others--that strip or encode potentially dangerous characters and sequences. Beyond basic sanitization, implement validation that checks data against expected formats, ranges, and business rules. Never directly insert user input into database queries, and always use WordPress's prepare() method or placeholder system to prevent SQL injection attacks. Custom endpoints should define argument schemas that specify required fields, expected types, and sanitization callbacks for each parameter.
Custom Endpoints and Advanced Usage
While the built-in WordPress REST API endpoints cover most common use cases, many applications require custom endpoints tailored to specific business logic or data structures. The REST API infrastructure provides a comprehensive registration system that allows you to expose any PHP function or method as an API endpoint, complete with authentication requirements, argument validation, and response formatting. Custom endpoints enable you to create APIs that precisely match your application's needs, exposing only the functionality required while maintaining consistent security and performance characteristics.
1<?php2/**3 * Register custom REST API endpoints4 * Add to theme's functions.php or custom plugin5 */6 7add_action('rest_api_init', function() {8 // Register analytics endpoint9 register_rest_route('custom/v1', '/analytics', [10 'methods' => 'GET',11 'callback' => 'get_analytics_data',12 'permission_callback' => function() {13 return current_user_can('edit_others_posts');14 },15 'args' => [16 'start_date' => [17 'required' => true,18 'sanitize_callback' => 'sanitize_text_field',19 'validate_callback' => function($param) {20 return preg_match('/^\d{4}-\d{2}-\d{2}$/', $param);21 }22 ],23 'end_date' => [24 'required' => true,25 'sanitize_callback' => 'sanitize_text_field',26 'validate_callback' => function($param) {27 return preg_match('/^\d{4}-\d{2}-\d{2}$/', $param);28 }29 ],30 'metric' => [31 'required' => false,32 'default' => 'pageviews',33 'sanitize_callback' => 'sanitize_text_field',34 'enum' => ['pageviews', 'visitors', 'bounce_rate', 'avg_time']35 ]36 ]37 ]);38 39 // Register search endpoint with enhanced results40 register_rest_route('custom/v1', '/enhanced-search', [41 'methods' => 'GET',42 'callback' => 'enhanced_search_results',43 'permission_callback' => '__return_true',44 'args' => [45 'q' => [46 'required' => true,47 'sanitize_callback' => 'sanitize_text_field',48 'min_length' => 249 ],50 'limit' => [51 'required' => false,52 'default' => 10,53 'sanitize_callback' => 'absint',54 'validate_callback' => function($param) {55 return $param > 0 && $param <= 100;56 }57 ]58 ]59 ]);60});61 62function get_analytics_data($request) {63 $start = $request->get_param('start_date');64 $end = $request->get_param('end_date');65 $metric = $request->get_param('metric');66 67 // Validate date range68 if (strtotime($start) > strtotime($end)) {69 return new WP_Error(70 'invalid_date_range',71 'Start date must be before end date',72 ['status' => 400]73 );74 }75 76 // Fetch and process analytics data77 $data = process_analytics($start, $end, $metric);78 79 return rest_ensure_response([80 'data' => $data,81 'meta' => [82 'start_date' => $start,83 'end_date' => $end,84 'metric' => $metric,85 'generated_at' => current_time('mysql')86 ]87 ]);88}89 90function enhanced_search_results($request) {91 $query = $request->get_param('q');92 $limit = $request->get_param('limit');93 94 // Search posts95 $posts_query = new WP_Query([96 's' => $query,97 'post_type' => ['post', 'page'],98 'posts_per_page' => $limit,99 'post_status' => 'publish'100 ]);101 102 $results = [];103 while ($posts_query->have_posts()) {104 $posts_query->the_post();105 $results[] = [106 'id' => get_the_ID(),107 'title' => get_the_title(),108 'excerpt' => wp_trim_words(get_the_excerpt(), 20),109 'url' => get_permalink(),110 'type' => get_post_type(),111 'date' => get_the_date('Y-m-d')112 ];113 }114 wp_reset_postdata();115 116 return rest_ensure_response([117 'query' => $query,118 'total' => $posts_query->found_posts,119 'results' => $results120 ]);121}Frequently Asked Questions
Sources
- WordPress REST API Handbook - Official WordPress documentation
- Hostinger - WordPress REST API Tutorial - Beginner-friendly tutorial with practical examples
- Jetpack - WordPress REST API Resources - Security-focused implementation guide
- ThriveWP - WordPress REST API Tutorial - Step-by-step implementation guide