WordPress API Integration: How to Connect Your Site to CRMs, ERPs and Payment Systems

WordPress API integration is what turns a website from a brochure into part of your business: leads flow into the CRM automatically, orders sync with the ERP, invoices go to the accounting tool, bookings land in the calendar, and your team stops copy-pasting between tabs. WordPress is unusually good at this – it has a complete REST API, webhooks, scheduled tasks and a plugin architecture designed for exactly this kind of glue – but most integrations I am asked to fix were built as a pile of fragile “connector” plugins that break on every update.

This guide explains how WordPress integrations actually work, the four integration patterns (push, pull, webhook, middleware), how to choose between a connector plugin, an automation platform and custom code, the security rules you cannot skip, and worked examples for CRMs, ERPs, payment gateways, booking, email marketing and AI services – with code where it helps. It is written for business owners and agency teams deciding how to connect things, and for developers who want a checklist.

Table of contents

• How WordPress integrations work: REST API, webhooks, cron
• The four integration patterns
• Connector plugin vs automation platform vs custom code
• Example 1 – Leads into a CRM (HubSpot, Pipedrive, Salesforce)
• Example 2 – WooCommerce orders and stock with an ERP or POS
• Example 3 – Payment gateways and webhooks
• Example 4 – Booking, calendars and appointments
• Example 5 – Email marketing and transactional email
• Example 6 – AI services (OpenAI, Claude) as integrations
• Exposing your WordPress data to other systems
• Security and reliability rules
• Cost, timeline and what to ask a developer
• Frequently asked questions

How WordPress integrations work: REST API, webhooks, cron

Three building blocks cover almost every integration:

• The WordPress REST API (/wp-json/) lets other systems read and write posts, pages, users, media, WooCommerce products/orders/customers – and lets you add your own endpoints for anything custom. Authentication: application passwords (core), OAuth or JWT (plugins), WooCommerce’s consumer key/secret.
• Outgoing HTTP requests from WordPress (wp_remote_post/get) call third-party APIs: create a CRM contact when a form is submitted, fetch stock levels from an ERP, ask an AI model for a summary.
• Webhooks in both directions: WordPress/WooCommerce can fire webhooks on events (order created, product updated), and a custom endpoint can receive webhooks from Stripe, a CRM or an ERP to react instantly instead of polling.
• WP-Cron / Action Scheduler for scheduled and background work: nightly stock sync, retrying failed requests, batching large imports.

Under the hood, every integration is a combination of these: an event in one system, a transformation of the data, an authenticated request to the other system, and error handling for when it fails – because it will, at 3 a.m., during a promotion.

The four integration patterns

1. Push (WordPress → external system)

Something happens in WordPress and you send data out immediately: a form submission becomes a CRM lead, a new order becomes an invoice draft. Simple, real-time, and the most common pattern. The essential detail is what happens when the external API is down: queue and retry, never lose the lead.

2. Pull (external system → WordPress on a schedule)

WordPress fetches data periodically: product prices and stock from the ERP every 15 minutes, events from a ticketing system hourly, exchange rates daily. Good for data that changes on the other side and needs to be displayed. Key details: only update what changed (compare hashes or timestamps), run it in the background, log the result.

3. Webhook (external system → WordPress instantly)

The other system calls a WordPress endpoint when something happens: Stripe says “payment succeeded”, the CRM says “deal won”, the warehouse says “shipped”. Real-time and efficient, but the endpoint must verify signatures, be idempotent (the same webhook can arrive twice) and respond fast (do the heavy work in the background).

4. Middleware (an automation layer in between)

Zapier, Make, n8n or a small custom service sits between WordPress and the rest: WordPress sends a generic webhook, the middleware maps fields and fans out to three tools. Fast to set up, great for non-developers, and fine for moderate volumes; the trade-offs are per-task pricing, another vendor in the chain, and limited control over failures and data formats.

Connector plugin vs automation platform vs custom code

My rule of thumb: if the integration is core to how you make money or serve customers – orders, payments, leads, bookings – build it properly as a small custom plugin. If it is a convenience automation that changes often, use an automation platform. Use connector plugins for the standard, low-stakes links, and never more than a few of them. This is the work on my WordPress API integration page, and it is also how the AI features I build plug in (see the AI solutions service).

Example 1 – Leads into a CRM (HubSpot, Pipedrive, Salesforce, Zoho)

The most requested integration. A good implementation:

1. The form (native, Gravity Forms, WPForms, Fluent Forms or a custom one) saves the submission in WordPress first – so nothing is lost if the CRM is down.
2. On submit, a hook pushes the lead to the CRM API: create or update the contact (match by email), create a deal/opportunity in the right pipeline, attach the source (page, campaign, UTM parameters), and add notes/answers as properties.
3. Failures are queued with Action Scheduler and retried with backoff; after three failures, you get an email.
4. Optional: a webhook from the CRM back to WordPress (“deal won”) to trigger an onboarding email or unlock a client area.

// on form submit: create/update the CRM contact, queue on failure
add_action( 'mysite_form_submitted', function ( $lead_id ) {
    $lead = mysite_get_lead( $lead_id );        // stored in WP first
    $ok   = mysite_crm_upsert_contact( $lead );  // wp_remote_post with the API key from wp-config
    if ( ! $ok ) {
        as_schedule_single_action( time() + 300, 'mysite_crm_retry', array( $lead_id ), 'mysite' );
    }
} );
add_action( 'mysite_crm_retry', function ( $lead_id ) {
    if ( ! mysite_crm_upsert_contact( mysite_get_lead( $lead_id ) ) ) {
        $tries = (int) get_post_meta( $lead_id, '_crm_tries', true ) + 1;
        update_post_meta( $lead_id, '_crm_tries', $tries );
        if ( $tries < 3 ) {
            as_schedule_single_action( time() + 900 * $tries, 'mysite_crm_retry', array( $lead_id ), 'mysite' );
        } else {
            wp_mail( get_option( 'admin_email' ), 'CRM sync failed for lead #' . $lead_id, 'Please check the CRM integration.' );
        }
    }
} );

Store first, push second, retry on failure, alert when stuck – that pattern is 80% of integration reliability.

Example 2 – WooCommerce orders and stock with an ERP or POS

Stores with a back-office system need two flows: orders out (WooCommerce → ERP for fulfilment and accounting) and products/stock/prices in (ERP → WooCommerce). The details that make or break it:

• Orders out: push on woocommerce_order_status_processing (paid), map line items by SKU, include shipping, tax and discounts explicitly, store the ERP order ID back on the Woo order, and write a note on the order with the result. Mark the order as “synced” so it is never pushed twice.
• Stock and prices in: delta sync every 5-15 minutes via the ERP’s API or an exported feed; update only changed SKUs; handle variations; log what changed. Full resyncs nightly. Never let a failed sync set stock to zero across the catalogue – validate the payload size first.
• Shipping status back: ERP/warehouse webhook → Woo order status “completed” with tracking number → customer email.
• Performance: batch updates, use the WooCommerce REST API or direct CRUD functions, avoid firing every hook for each of 5,000 products (disable emails and cache flushes during bulk updates).
• Reconciliation: a daily report comparing order totals and stock on both sides catches silent drift.

POS systems (Square, Lightspeed, Clover) work the same way with stock as the shared truth; the challenge is usually the SKU mapping and tax rules, not the HTTP calls.

Example 3 – Payment gateways and webhooks

WooCommerce gateways (Stripe, PayPal, Mollie, Razorpay, Adyen) are integrations you mostly configure, but custom work appears with subscriptions, split payments, deposits, B2B invoicing, or non-Woo payment flows (donations, course purchases, booking deposits). The principles:

• Create the payment intent/session server-side; never trust amounts from the browser.
• Treat the webhook as the source of truth for “paid” – not the redirect back to your thank-you page, which the customer may never reach.
• Verify the webhook signature, make handlers idempotent (the same event can be delivered more than once), respond 200 quickly and process in the background.
• Log every event with its ID; keep refunds/disputes flowing back into order status.

// minimal webhook receiver (custom endpoint) - verify, dedupe, queue
register_rest_route( 'mysite/v1', '/stripe-webhook', array(
  'methods' => 'POST',
  'permission_callback' => '__return_true',
  'callback' => function ( WP_REST_Request $r ) {
    $payload = $r->get_body();
    $sig     = $r->get_header( 'stripe-signature' );
    if ( ! mysite_stripe_signature_valid( $payload, $sig, MYSITE_STRIPE_WEBHOOK_SECRET ) ) {
        return new WP_REST_Response( 'bad signature', 400 );
    }
    $event = json_decode( $payload, true );
    if ( get_transient( 'stripe_evt_' . $event['id'] ) ) {
        return new WP_REST_Response( 'duplicate', 200 );   // idempotent
    }
    set_transient( 'stripe_evt_' . $event['id'], 1, DAY_IN_SECONDS );
    as_enqueue_async_action( 'mysite_handle_stripe_event', array( $event ), 'mysite' );
    return new WP_REST_Response( 'ok', 200 );
  },
) );

Example 4 – Booking, calendars and appointments

Consultants, clinics, studios and rentals need availability, booking, reminders and sometimes payment. Options range from embedding Calendly/Cal.com (fast, little control) to booking plugins (Amelia, Bookly, Simply Schedule) to custom flows that check availability against Google/Outlook calendars via API, take a deposit, create the event, send reminders, and push the customer into the CRM. The custom route makes sense when the booking logic is specific (resources, staff, durations, buffer times, multi-step intake forms) or when the booking must sync with an existing system – which is usually exactly when the plugin’s assumptions break.

Example 5 – Email marketing and transactional email

• Lists and automations: subscribers from forms and checkout go to Mailchimp/Klaviyo/Brevo/ActiveCampaign with tags for source and interest; purchases trigger flows. Most platforms have official WordPress/Woo plugins – use them; add custom code only for unusual mapping or consent logic.
• Transactional email: WordPress should never send order confirmations or password resets through the web server. Route wp_mail() through an SMTP/API service (Postmark, SendGrid, Brevo, Google Workspace) with SPF/DKIM/DMARC set – deliverability is an integration, too.
• Inbound: parse replies or support emails into WordPress (tickets, inquiries) via the provider’s inbound webhook.

Example 6 – AI services (OpenAI, Claude) as integrations

AI features are “just” API integrations with a few extra rules: the key stays on the server, calls are rate-limited and capped by spend, inputs are minimised (privacy), outputs are validated before they touch your data, and expensive calls run in the background. Typical WordPress uses: a support assistant on the site, automatic product descriptions and alt text drafts, lead qualification and routing, summarising long form submissions for the sales inbox, translating content for review, classifying support tickets. I covered the assistant case in detail in how to add an AI chatbot to WordPress; the same endpoint pattern (nonce, rate limit, server-side key, short context) applies to every AI integration.

Exposing your WordPress data to other systems

Integrations also run the other way: a mobile app, a partner, a dashboard or a second website reads from WordPress. The REST API covers posts, pages, media, users and (via WooCommerce) products, orders and customers out of the box. For custom post types, register them with show_in_rest; for custom data, add endpoints with proper permission callbacks; for partners, issue application passwords or API keys per partner with the least privilege needed; rate-limit and log. And hide what should not be public – the users endpoint, drafts, internal fields – as part of the security basics.

Eight integration recipes I build most often

• Contact form → CRM + Slack/Teams notification with lead scoring fields and UTM source; retries on CRM failure.
• WooCommerce order → invoicing/accounting (Xero, QuickBooks, sevDesk, Lexoffice, Zoho Books): invoice created on payment, PDF attached to the order email, status synced back on payment in the accounting tool.
• Inventory feed → products from a supplier CSV/XML/API: scheduled delta import with price rules, image import once, out-of-stock handling and a change log the owner can read.
• Newsletter and marketing automation with consent tags from checkout and forms; purchases and categories pushed as events for flows.
• Booking engine ↔ Google/Outlook calendars with availability checks, deposits via Stripe and reminder emails/SMS.
• Membership/course platform ↔ payments (subscription webhooks control access levels; failed payments trigger grace periods and emails).
• Google Sheets / Airtable as a lightweight back office: orders or leads appended in real time for teams who live in spreadsheets; changes flow back via a small sync.
• AI enrichment: summarise enquiries, classify tickets, draft replies, generate product copy – with a human approval step (ideas in AI automation ideas for WordPress).

Testing an integration before go-live

Integrations fail at the edges, so the test plan is about the edges: the happy path once, then – the external API returns 500 or times out (does the lead queue and retry? does the page still respond?); the API returns a validation error (is it logged with the payload so someone can fix the mapping?); the same webhook arrives twice (no duplicate order or double email?); a record with missing optional fields (no PHP warnings, sensible defaults?); characters that break things (umlauts, emojis, apostrophes in names); rate limits (does the sync back off?); a 5,000-row import (memory, time limits, progress); and credentials rotated (clear error, no silent failure). Run all of that on staging against the service’s sandbox, then a small live pilot (one day of real traffic with extra logging) before you switch off the old manual process. Finally, write down how to tell the integration is healthy – a daily count, a reconciliation, a heartbeat – and put it in the maintenance routine.

Security and reliability rules

1. Secrets in wp-config.php or the host’s secrets manager, never in plugin options that export with the database and never in the browser.
2. Verify everything inbound: webhook signatures, nonces, capabilities, input types; reject unknown payloads.
3. Least privilege for API keys on both sides (read-only where possible, scoped tokens, per-partner keys).
4. Idempotency: every handler must be safe to run twice (orders, payments, leads).
5. Queue + retry + backoff for outbound calls; never block a visitor’s page on a third-party API.
6. Timeouts on every request (5-15 s) and graceful degradation when the other side is down.
7. Logging with request IDs, and alerts when failures exceed a threshold – silent failures are the most expensive kind.
8. Data minimisation and consent for personal data; a DPA with every processor; document the flows for your privacy policy.
9. Staging + sandbox accounts for every integrated service; test failure paths (declined card, API 500, malformed webhook), not only the happy path.
10. Monitoring after launch: a daily reconciliation or health check that proves the integration still works.

Headless and decoupled setups

A related use of the REST API is headless WordPress: WordPress remains the content management system, a separate front end (Next.js, Nuxt, a mobile app) reads content via REST or GraphQL. It is powerful for apps and multi-channel publishing, and it is usually overkill for a business website – you lose the editor preview, themes, many plugins and simplicity, and you take on two deployments. In integration projects the question comes up as “should we go headless to integrate X?” and the answer is almost always no: WordPress can call and receive from X directly, keep its templates, and stay simple to maintain. Reserve headless for genuine multi-front-end needs; for everything else, integrate inside WordPress with the patterns above.

Documentation: the part that outlives the developer

Every integration I deliver comes with a one-page document: what triggers it, what it sends where, how failures are handled and where to see them, which credentials it uses and where they are stored, how to test it, and how to switch it off safely. It sounds bureaucratic; it is what lets a business change developers, rotate a key or debug a problem at 9 a.m. on a Monday without archaeology. Ask for it in the quote.

Cost, timeline and what to ask a developer

A single well-built integration (form → CRM with retries, or Woo → ERP orders) is typically one to two weeks of development including testing; a two-way ERP sync with stock, prices and shipping status is two to five weeks; payment or booking flows depend on the logic. I quote fixed prices per integration after a short discovery call where we map the fields and the failure cases.

When you evaluate a developer or agency, ask: Where does the API key live? What happens when the other API is down? Is the handler idempotent? How do I know it is still working in three months? How is this documented? Clear answers to those five questions separate an integration from a liability.

Need something connected?

CRM, ERP, POS, payments, booking, email, AI – I build WordPress and WooCommerce integrations as small, documented plugins with queues, retries and monitoring, for businesses and as white-label work for agencies. See the API integration service or describe what needs to talk to what – I reply within 24 hours.

Frequently asked questions

Can WordPress integrate with a CRM like HubSpot or Salesforce?

Yes. Forms and WooCommerce events can create or update contacts and deals through the CRM’s API, either via the CRM’s official plugin, an automation platform, or a custom integration that adds field mapping, retries and two-way webhooks.

What is the WordPress REST API used for?

It lets other systems read and write WordPress data (posts, pages, media, users, WooCommerce products and orders) and lets developers add custom endpoints – the foundation for mobile apps, headless front ends, partner integrations and webhooks into WordPress.

Is Zapier good enough for WordPress integrations?

For low-volume, non-critical automations, yes. For core business flows (orders, payments, leads at scale) a custom integration is more reliable, cheaper at volume and keeps data between you and the other system only.

How do I connect WooCommerce to an ERP?

Push paid orders to the ERP (mapped by SKU, with the ERP order ID stored on the order), pull products/stock/prices in on a schedule as delta updates, receive shipping status via webhook, and run a daily reconciliation. Build it as a dedicated plugin with queues and logging.

How do WordPress webhooks work?

WordPress and WooCommerce can send webhooks on events (order created, post published) and a custom REST endpoint can receive webhooks from other services. Receivers must verify signatures, handle duplicates and respond quickly while processing in the background.

Are WordPress API integrations secure?

They are as secure as their implementation: secrets on the server, signature and permission checks, least-privilege keys, input validation, HTTPS, logging and monitoring. Done that way, WordPress integrations meet the same bar as any other backend.

How much does a WordPress API integration cost?

A single standard integration is usually one to two weeks of work; complex two-way syncs two to five weeks. Costs scale with field mapping, business rules and failure handling rather than with the API itself. Ask for a fixed quote after a field-mapping call.