WordPress REST API
The REST API built into WordPress core (since 4.7) that exposes posts, pages, media, users, taxonomies, and custom post types as JSON endpoints — enabling headless WordPress, mobile app backends, and external content management from agents.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
TLS is strongly recommended but not enforced by the API itself — HTTP instances exist in the wild. Application Passwords are a reasonable mechanism but inherit full user role permissions with no scope restriction. No built-in rate limiting is a DoS risk. WordPress's large plugin ecosystem introduces significant supply chain risk. Core security is generally good; the ecosystem is not.
⚡ Reliability
Best When
You already have WordPress deployed and need programmatic access to content, or you need headless CMS capabilities on top of an existing WordPress site without migrating the content.
Avoid When
You're starting fresh and want a clean, modern CMS API — the WordPress REST API carries significant historical design debt and the auth story for agents is awkward.
Use Cases
- • Headless WordPress — fetching content for React/Next.js frontends
- • Publishing posts and managing content programmatically from agents or CI pipelines
- • Syncing WordPress content with external systems (CRMs, marketing tools)
- • Reading and updating custom post types and custom fields via agent workflows
- • Media library management (upload, organize) from automated processes
Not For
- • Teams who need a modern API-first CMS from the ground up (use Ghost or Contentful instead)
- • High-performance content delivery at CDN scale without additional caching layers
- • Complex relational data models — WordPress's flat post/meta structure poorly fits structured data
- • Teams without a WordPress instance already deployed
Interface
Authentication
Application Passwords (built-in since WP 5.6) is the recommended method for agent access — generates a credential per-application without exposing the user password. OAuth 2.0 requires a plugin (WP OAuth Server). JWT auth also requires a plugin. Cookie auth is only valid for same-origin browser requests. No built-in scope system — Application Passwords inherit full user role permissions.
Pricing
The REST API is part of WordPress core and completely free. Hosting costs vary. WordPress.com's cheapest plans may restrict API access; self-hosted WordPress has full API access with no restrictions.
Agent Metadata
Known Gotchas
- ⚠ Application Passwords require the WordPress site to use HTTPS — HTTP sites cannot use Application Passwords
- ⚠ No built-in rate limiting means a misbehaving agent can DoS a shared WordPress host
- ⚠ Custom post types and custom fields (ACF, etc.) are not automatically exposed in the REST API — they must be explicitly registered with show_in_rest: true
- ⚠ The API returns HTML-encoded content by default — agents parsing post content must handle HTML, not plain text
- ⚠ Pagination uses X-WP-Total and X-WP-TotalPages response headers, not body fields — easy to miss
- ⚠ Nonces (CSRF tokens) expire — agents using cookie auth in browser contexts must handle 403 nonce expiry
- ⚠ WordPress.com and self-hosted WordPress have different API base URLs and different authentication flows
- ⚠ No built-in webhook system — must use plugins (WP Webhooks, etc.) to get event notifications
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for WordPress REST API.
Scores are editorial opinions as of 2026-03-06.