WordPress REST API as a Mobile Backend: A Practical Guide

What the WP REST API Gives You Out of the Box

A default WordPress install exposes the following via REST API at /wp-json/wp/v2/:

Posts, pages, users, categories, tags, and media library items — all as JSON endpoints with filtering, pagination, and field selection built in. You can retrieve only the fields your app needs, reducing response size considerably on slower connections.

Custom post types registered with show_in_rest => true get their own endpoints automatically. A “Properties” CPT becomes /wp-json/wp/v2/properties. ACF fields can be exposed via the ACF to REST API plugin, making your custom field data available alongside post data.

For a mobile app that reads content from a WordPress-based business, this is a significant head start.

Authentication

Read endpoints for public content require no authentication. Write operations and protected content require it.

For mobile apps, JWT authentication is the right approach. The JWT Authentication for WP REST API plugin adds a /wp-json/jwt-auth/v1/token endpoint. The mobile app sends credentials, receives a JWT token, and includes it in the Authorization: Bearer <token> header on subsequent requests.

Token refresh management is important for UX: JWTs expire, and you need to handle 401 responses gracefully — either refreshing the token automatically or prompting re-authentication without disrupting the user’s session. Build this into your API client layer from the start, not as an afterthought.

Custom Endpoints for Business Logic

The built-in endpoints handle CRUD operations on WordPress objects. Business logic — “get all available properties in this price range with agent contact info” — requires custom endpoints.

Custom REST endpoints are registered with register_rest_route():

register_rest_route('myapp/v1', '/properties', [
  'methods' => 'GET',
  'callback' => 'get_filtered_properties',
  'permission_callback' => '__return_true',
  'args' => [
    'min_price' => ['type' => 'integer'],
    'max_price' => ['type' => 'integer'],
    'location' => ['type' => 'string'],
  ]
]);

The callback function runs the query, assembles the response shape your mobile app expects, and returns it. WordPress provides the routing, authentication check, and schema validation infrastructure — you provide the business logic.

Performance Considerations

The WordPress REST API is convenient but not inherently fast. Each endpoint request bootstraps WordPress completely — loading plugins, themes, and the full application stack. For high-traffic apps, this becomes a bottleneck.

Cache endpoint responses. Use transients or an object cache layer. A property search endpoint that takes 400ms uncached can return in 20ms from cache. For frequently-read data that changes infrequently, transient caching with a 15-minute expiry is often sufficient.

Disable unused API routes. WordPress exposes many endpoints by default — user lists, oEmbed, block editor endpoints — that your app doesn’t need. Unregistering unused routes reduces attack surface and speeds up route matching.

Use the _fields parameter. Instead of requesting full post objects, specify only the fields your app needs: ?_fields=id,title,acf.price,acf.location. This reduces JSON payload size significantly, which matters on Caribbean mobile connections.

Security Considerations

The default WordPress REST API exposes user enumeration via the /wp-json/wp/v2/users endpoint. Disable this for unauthenticated requests if you’re not using it.

Validate and sanitize all input on custom endpoints. WordPress provides sanitization functions — use them. Never pass raw user input directly into WP_Query arguments.

Rate limiting REST API endpoints prevents abuse. A simple transient-based rate limiter on write endpoints is sufficient for most apps.

When Not to Use the WP REST API

The WP REST API is the right choice when your app primarily reads WordPress content, write operations are infrequent, and the existing WordPress data structure maps well to your app’s needs.

It’s the wrong choice when: your app has complex business logic that doesn’t map to WordPress’s data model; you need real-time features like WebSockets or live updates; your app handles sensitive transactions requiring audit trails and rollback capability beyond WordPress’s native tooling; or performance requirements exceed what WordPress can sustain even with caching.