XMLRPC.php: WordPress XML-RPC vs REST API for Managing WordPress Integrations

Use the WordPress REST API for new integrations, and keep xmlrpc.php only when a legacy app still depends on it. XML-RPC still works, but it carries more security baggage, weaker developer ergonomics, and fewer modern controls than the REST API.

What xmlrpc.php actually does

xmlrpc.php is a core WordPress file that allows remote systems to talk to a WordPress site. It uses the XML-RPC protocol, which sends XML payloads over HTTP. Before the REST API matured, XML-RPC handled remote publishing, mobile app connections, pingbacks, and some plugin integrations.

In practical terms, XML-RPC can let another system:

• Publish or edit posts.
• Upload media files.
• Read comments.
• Authenticate a user.
• Send pingbacks from other sites.

That sounds useful. It was. The problem is that the same entry point can also be abused. Attackers often target xmlrpc.php because it is predictable, widely available, and historically tied to brute force login attempts and pingback abuse.

What the WordPress REST API does differently

The WordPress REST API exposes site data through structured HTTP endpoints, usually returning JSON. It is easier for modern applications to read, test, and secure. Most web developers already know how to work with REST endpoints, status codes, headers, tokens, and JSON payloads.

A REST endpoint might look like this:

/wp-json/wp/v2/posts

That endpoint can be used to fetch posts, create posts, update records, or connect WordPress with external systems such as CRMs, mobile apps, dashboards, static site builders, and marketing platforms.

The REST API is not automatically secure just because it is newer. Bad authentication, excessive permissions, and exposed custom endpoints can still cause serious trouble. But REST gives teams better tools to control access, log behavior, and build predictable integrations.

Security comparison: XML-RPC vs REST API

Security is the main reason many site owners inspect xmlrpc.php. Honestly, it feels like an old side door that nobody wants to check until server logs start filling with junk requests.

XML-RPC often attracts these problems:

• Brute force amplification: The system.multicall method can bundle many login attempts into one request.
• Pingback abuse: Attackers may use pingbacks to create unwanted traffic or assist denial of service attacks.
• Poor visibility: XML payloads can be harder to inspect and debug than clear REST requests.
• Legacy assumptions: Older tools may rely on username and password authentication.

The REST API has risks too:

• Exposed user data: Poor endpoint configuration can reveal more information than expected.
• Weak custom endpoints: Plugin developers sometimes forget permission checks.
• Token mishandling: Application passwords and API tokens need careful storage.

Still, REST usually wins for controlled business integrations. It supports clearer permission logic, better monitoring, and cleaner request patterns.

Performance and reliability

REST calls are usually simpler to optimize. JSON is lighter and easier to parse than XML. Caching layers, proxies, firewalls, and monitoring tools also tend to understand REST traffic better.

XML-RPC can work fine for small jobs. A mobile app publishing a single draft will not crush a server. But batch operations can become awkward. XML payloads are verbose, error messages can be vague, and debugging often takes longer than it should.

Expect to waste time on small XML-RPC failures. A malformed XML character can turn a simple post update into a 20-minute log hunt. REST errors are usually more direct, with cleaner status codes such as 401, 403, or 404.

Best use cases for XML-RPC

XML-RPC is not useless. It is just rarely the best first choice now. Keep it enabled only when there is a clear need.

Common valid XML-RPC use cases include:

• Jetpack features that still depend on XML-RPC communication.
• Older mobile publishing workflows that have not moved to REST.
• Legacy desktop blog editors used by editorial teams.
• Existing integrations where replacement would cost more than the risk justifies.

If none of these apply, disabling XML-RPC is often reasonable. Many security plugins let you block it fully or restrict selected methods. A firewall rule can also block direct access to xmlrpc.php.

Best use cases for the REST API

The REST API fits most modern integration work. It is the better option for:

• Headless WordPress builds.
• Mobile apps that need content from WordPress.
• CRM and marketing automation connections.
• Internal dashboards for editorial or sales teams.
• Custom plugin integrations with strict permissions.
• Content migration tools that need repeatable requests.

REST also works better with modern authentication patterns. WordPress application passwords, OAuth solutions, JWT implementations, and server-side token storage all pair more naturally with REST than XML-RPC.

How to decide which one to use

The decision should be practical, not emotional. Use this simple rule:

• Choose REST API for all new WordPress integrations.
• Keep XML-RPC only for a verified legacy requirement.
• Disable XML-RPC if no active service depends on it.
• Restrict XML-RPC if only one trusted service needs access.

Before disabling XML-RPC, check your site logs and plugin documentation. Test Jetpack, mobile publishing, remote posting tools, uptime monitors, and editorial workflows. Breaking a business process is not security. It is just a different outage.

Recommended setup for serious WordPress integrations

For a stable production site, treat remote access as a controlled surface. Do not leave old endpoints open “just in case.” That habit creates quiet risk.

A sensible setup looks like this:

• Use the REST API for new integrations and custom development.
• Require HTTPS for every API request.
• Use application passwords or token-based authentication instead of normal admin passwords where possible.
• Give integrations the lowest required role, not full administrator access.
• Log failed API requests and review unusual spikes.
• Block or restrict xmlrpc.php if it is not needed.
• Review custom REST endpoints for permission checks.

For high-traffic sites, add rate limiting. If one integration normally sends 500 requests per hour, a sudden jump to 20,000 requests deserves attention. Your firewall or hosting provider should help apply those limits without hurting normal users.

Final recommendation

The REST API should be your standard choice for managing WordPress integrations. It is cleaner, easier to secure, and better suited to current development practices. XML-RPC remains part of WordPress history and still supports some older services, but it should not be left open without a reason.

If you manage a business site, audit xmlrpc.php now. Confirm whether anything uses it. If not, disable it. If yes, restrict access and plan a move to the REST API when practical. That small cleanup can reduce noise, lower risk, and make future integrations easier to maintain.