WordPress rarely lives alone in an enterprise. It needs to talk to a CRM, an ERP, a student information system, a payment gateway, a single sign on provider and, more and more, an AI model. The REST API, built into core since WordPress 4.7, makes WordPress a first class citizen in that ecosystem. The difference between a reliable integration and a fragile one comes down to a few patterns.
Know the two directions
Integrations flow in two directions. Inbound means other systems read from or write to WordPress, through the core REST API or custom endpoints. Outbound means WordPress calls other services, usually through the HTTP API with wp_remote_get and wp_remote_post. Most projects need both, and each has its own concerns.
Inbound: custom endpoints done right
Core endpoints cover posts, pages, media, users and any custom post type registered with show_in_rest. When you need something more specific, register a custom route with register_rest_route. Every custom route we write has:
- A permission_callback that checks a real capability, never one that returns true for private data
- An args schema that validates and sanitizes every parameter
- Clear, versioned namespaces such as alphaweb/v1 so you can evolve without breaking clients
- Consistent error responses using WP_Error with proper HTTP status codes
For machine to machine access, Application Passwords in core are a solid default. For larger setups we use OAuth or JWT through a vetted plugin, scoped to the minimum capability needed.
Outbound: never block the page on a third party
The most common integration bug we fix is a page that calls an external API during the request. When that API is slow, the site is slow. When it is down, the site breaks. Instead:
- Fetch on a schedule with WP Cron or a real system cron and store results locally
- Cache responses in transients or the object cache with sensible expirations
- Push slow work into a background queue, such as Action Scheduler, which WooCommerce also uses
- Set timeouts on every request and fail gracefully with cached data
The Campbell Soup Company recipe importer is a good example: content flows in on a schedule, so the public site never waits on an upstream system.
Webhooks over polling
When the other system supports webhooks, use them. A signed webhook into a custom endpoint, verified with a shared secret, keeps data fresh without hammering an API. We log every webhook and make handlers idempotent so a repeated delivery does not create duplicates.
Adding AI the same way
AI services are just another outbound integration, and the same rules apply. We connect WordPress to providers such as xAI, Anthropic, OpenAI and Google through server side calls so API keys never reach the browser. Typical features include:
- Draft summaries, excerpts and meta descriptions that an editor reviews before publishing
- Alt text suggestions for the media library
- Semantic site search that answers questions from your own published content
- Tagging and classification of large archives
The key is that a human approves anything public, prompts and outputs are logged, and private data is never sent to a model without a clear agreement. We cover this in depth in our practical guide to AI in WordPress and on our AI implementation consulting page.
Secrets and configuration
Credentials belong in environment variables or wp-config constants, never in the database options table where any plugin can read them, and never in Git. Each environment gets its own keys, and staging should point at sandbox services so tests do not send real emails or charge real cards.
Monitor what you connect
Integrations fail quietly. A token expires, a vendor changes a field name, or a nightly sync stops running and nobody notices for a week. We add health checks for every connection, log failures with enough context to debug them, and alert a real person when a sync misses its window. A simple admin screen that shows the last successful run of each integration saves hours of guessing.
Versioning your own API
If other teams or apps depend on your custom endpoints, treat them like a product. Version the namespace, document every route with its parameters and response shape, and never remove a field without a deprecation period. WordPress exposes a discovery index at /wp-json/ that lists available routes, and we supplement it with human friendly documentation. For high traffic read endpoints we add caching headers so a CDN can serve repeat requests, and we use the _fields parameter to keep responses small. Mobile apps, headless front ends and partner integrations all benefit from an API that is stable, fast and predictable. It is the same discipline that lets an app built with AppPresser read reliably from a WordPress site for years without breaking when the website changes.
Integration checklist
- Document every system, direction, data field and owner
- Permission callbacks and schemas on every custom route
- Application Passwords or OAuth with least privilege
- No synchronous third party calls on public page loads
- Caching, queues, timeouts and graceful fallbacks
- Signed, logged, idempotent webhooks
- Secrets in environment config, separate per environment
- Human review on all AI generated public content
Frequently asked questions
Is the WordPress REST API secure?
Yes, when endpoints have correct permission checks. Most REST vulnerabilities come from custom routes that skip them, which is why we review every one.
Can WordPress connect to Salesforce or HubSpot?
Yes, through official plugins or custom integrations. The right choice depends on volume and which fields need to sync.
Which AI provider do you recommend?
It depends on the task, cost and data policies. We often build provider neutral so you can switch later.
Planning an integration? Our WordPress development team can scope it.
