.png)
WordPress Integration Guide
Integrate WordPress with enterprise systems through its REST API, deployment-specific webhooks, media endpoints, and optional GraphQL extensions.
WordPress integration options at a glance
WordPress core provides a REST API for Posts, Pages, Media, Users, Comments, taxonomies, and custom routes. Martini can consume these endpoints to retrieve, create, update, and delete resources, while its workflows handle pagination, filtering, transformation, and downstream delivery. Application Passwords provide a practical server-to-server authentication method when HTTPS is enabled. GraphQL is available through the WPGraphQL plugin rather than WordPress core. Webhooks are deployment-specific: WordPress.com, plugins, hosting platforms, or custom code may provide selected event notifications. REST batch requests and the Media resource support bounded bulk operations and file synchronization.
| Integration point | Supported by WordPress? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | WordPress core exposes REST resources for Posts, Pages, Media, Users, Comments, taxonomies, and custom routes. Resources can generally be retrieved, created, updated, or deleted according to endpoint behavior and permissions. | Martini can consume the WordPress REST API, expose APIs for upstream systems, transform payloads, and orchestrate writes to WordPress or other platforms. |
| GraphQL APIs | Limited | WPGraphQL or another plugin can expose Posts, Pages, Media, Users, taxonomies, and plugin-specific data through a configurable GraphQL schema. | Martini can consume GraphQL endpoints when the target WordPress deployment has the required plugin and schema configured. |
| Webhooks | Limited | WordPress.com, plugins, hosting platforms, or custom code can provide notifications for selected events. WordPress core does not provide universal webhooks for every content change. | Martini can expose a webhook endpoint and start workflows, while scheduled polling can provide reconciliation when event coverage is incomplete. |
| Bulk / batch APIs | Limited | The REST batch endpoint can group multiple supported REST operations into one synchronous request. It is not a general asynchronous job API. | Martini can construct bounded batch requests, process responses, apply per-operation error handling, and fall back to individual calls when needed. |
| File / attachment APIs | Yes | The Media resource supports listing, uploading, updating, and associating images, documents, audio, video, and other uploaded files. | Martini can transfer binary content and metadata, map Media IDs to Posts or Pages, and coordinate WordPress with storage or DAM systems. |
| Authentication | Yes | Application Passwords support authenticated REST requests, while cookie and nonce authentication is intended mainly for requests within WordPress. OAuth or JWT may be supplied by WordPress.com or plugins. | Martini can store credentials in protected configuration, call authenticated endpoints, and separate authentication failures from permission and validation errors. |
| Database access | Not confirmed | WordPress commonly uses MySQL or MariaDB, but direct database access is not the standard external integration boundary and analytics access is deployment-specific. | Martini should generally consume WordPress APIs rather than depend on direct database access; database integration is suitable only when separately provisioned and supported by the environment. |
How WordPress exposes data and business events
WordPress REST APIs
WordPress core provides REST endpoints under paths such as /wp-json/wp/v2/posts, /pages, /media, /users, and /comments. Custom post types and plugin routes may be available when registered with REST support and authorized for the integration user.
Martini implementation pattern
Martini implementation pattern: a workflow calls the relevant WordPress endpoint, handles pagination and query filters, validates the response, maps the vendor model to a canonical model, and writes the result to a target or calls WordPress for an outbound update.
Implementation sequence
WordPress GraphQL APIs
WPGraphQL provides a GraphQL API through a plugin or extension; its schema and available objects depend on the WordPress deployment, enabled extensions, and configuration.
Martini implementation pattern
Martini implementation pattern: Martini sends a documented GraphQL query to the configured WordPress endpoint, handles the response and GraphQL errors separately, then transforms the selected fields into downstream objects. This method is appropriate only when the site operates a supported GraphQL extension.
Implementation sequence
WordPress webhooks
Webhook-style notifications are deployment-specific. WordPress.com, plugins, hosting platforms, or custom code may notify Martini about selected events, but WordPress core does not provide universal outbound webhooks.
Martini implementation pattern
Martini implementation pattern: Martini exposes a controlled API endpoint, validates the notification and any signature or shared secret supplied by the selected WordPress service, then retrieves the current resource from WordPress before processing it. Polling reconciliation should supplement incomplete event coverage.
Implementation sequence
WordPress Media and batch APIs
The Media REST resource supports file uploads and metadata operations, while the REST batch endpoint groups supported operations into a synchronous request. Both mechanisms remain subject to endpoint limits, permissions, and hosting controls.
Martini implementation pattern
Martini implementation pattern: a workflow stages the file or bounded operation set, calls WordPress with the correct content type and authentication, validates each result, and records returned Media IDs or per-operation outcomes for retry and reconciliation.
Implementation sequence
Common WordPress integration patterns
Pattern 1: Synchronize published content to an enterprise platform
When to use this pattern
Use this pattern when WordPress is the source for published Posts and Pages and another platform needs a searchable, governed, or reporting-ready copy. A scheduled workflow is appropriate when webhook coverage is incomplete.
Integration direction
Example Mapping
| WordPress Field | Canonical Field | Target Field |
|---|---|---|
| id | sourceContentId | externalSourceId |
| title.rendered | title | title |
| content.rendered | bodyHtml | body |
| modified | lastModifiedAt | updatedAt |
Martini implementation pattern
Martini schedules a paginated extraction using modified-date filters where supported, normalizes rendered content and taxonomy references, and upserts the target using the WordPress object ID. The workflow records a checkpoint, controls concurrency, and retries transient failures while routing validation or schema errors for review.
Martini capabilities used
- workflows
- scheduled triggers
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Publish approved content to WordPress
When to use this pattern
Use this pattern when an editorial or enterprise system approves content and WordPress is the publishing destination for Posts or Pages. It also supports related media uploads before publication.
Integration direction
Example Mapping
| WordPress Field | Canonical Field | Target Field |
|---|---|---|
| contentId | externalContentKey | meta.integrationKey |
| headline | title | title.raw |
| body | bodyHtml | content.raw |
| publicationState | status | status |
Martini implementation pattern
A Martini API or workflow trigger receives the approved payload, validates required fields and publication rules, uploads referenced files through the Media endpoint, and creates or updates the corresponding Post or Page. The workflow stores the returned WordPress ID and uses the external key to make retries idempotent.
Martini capabilities used
- APIs
- workflows
- data mapping
- file handling
- business rules
- idempotency
- error handling
Pattern 3: Synchronize WordPress media with storage
When to use this pattern
Use this pattern when Media files need to be copied to a DAM or cloud storage platform, or when an external asset source must publish files into WordPress with associated metadata.
Integration direction
Example Mapping
| WordPress Field | Canonical Field | Target Field |
|---|---|---|
| id | sourceMediaId | externalAssetId |
| source_url | assetUrl | sourceUrl |
| mime_type | contentType | mimeType |
| alt_text | alternativeText | altText |
Martini implementation pattern
Martini retrieves Media metadata and downloads the referenced file when accessible, then transfers the file and mapped metadata to the target. For reverse publication, it validates the source file, uploads Media to WordPress, and associates the returned ID with content. Large files use bounded processing and explicit timeout and retry policies.
Martini capabilities used
- workflows
- API consumption
- file handling
- data mapping
- validation
- error handling
Pattern 4: Detect WordPress changes with events and polling
When to use this pattern
Use this pattern when downstream teams need timely notifications for selected WordPress changes but the deployment has incomplete or deployment-specific webhook coverage. It combines event delivery with scheduled reconciliation.
Integration direction
Example Mapping
| WordPress Field | Canonical Field | Target Field |
|---|---|---|
| event.resource | objectType | notificationType |
| event.object_id | sourceObjectId | externalReference |
| modified | changedAt | eventTimestamp |
| status | contentStatus | workflowStatus |
Martini implementation pattern
Martini receives supported webhook notifications, validates the request, retrieves the current WordPress object, and routes it according to status and object type. A scheduled workflow polls modified resources to detect missed events, while stored IDs and timestamps prevent duplicate notifications and bounded retries handle transient API failures.
Martini capabilities used
- API exposure
- webhook consumption
- scheduled triggers
- change detection
- business rules
- deduplication
- monitoring
Applications commonly integrated with WordPress
WordPress is commonly used as a content and experience layer alongside marketing, commerce, collaboration, analytics, and enterprise applications. These integrations generally use WordPress REST endpoints, application APIs, plugins, or custom routes rather than a universal WordPress core connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| WooCommerce | Synchronize products, orders, customers, inventory, and website content across the WordPress commerce ecosystem and downstream business systems. | WooCommerce → Martini → ERP or finance platform | Martini can consume WooCommerce and WordPress APIs, normalize product and order data, apply inventory or fulfillment rules, and route updates to enterprise systems with idempotency and retry handling. |
| Salesforce | Send website leads, form submissions, campaign activity, or customer information to Salesforce and optionally return selected statuses or approved content. | WordPress → Martini → Salesforce | A Martini workflow can receive WordPress events or poll relevant REST resources, validate and map payloads to Salesforce API models, upsert using an external key, and route permission or validation failures for review. |
| HubSpot | Transfer contacts, form activity, marketing data, and campaign-related information generated through a WordPress site into HubSpot. | WordPress → Martini → HubSpot | Martini can orchestrate scheduled extraction or plugin-provided notifications, transform WordPress fields and consent data, call HubSpot APIs, and record source IDs to prevent duplicate contacts or submissions. |
| Mailchimp | Synchronize WordPress subscribers and consent-related fields with Mailchimp lists and support content- or registration-driven campaign processes. | WordPress → Martini → Mailchimp | Martini can receive or retrieve subscriber data, apply consent and audience rules, map fields to Mailchimp APIs, and retry transient failures without creating duplicate subscriptions. |
| Google Analytics | Combine WordPress site activity and attribution data with enterprise reporting and analytics processes. | WordPress → Martini → Google Analytics | Martini can coordinate WordPress metadata or plugin-provided analytics data with reporting workflows and retrieve available analytics outputs through the relevant Google APIs, subject to the configured tracking architecture. |
| Slack | Notify editorial, support, and operations teams about published Posts, moderation activity, form submissions, or integration exceptions. | WordPress → Martini → Slack | A webhook or scheduled Martini workflow can detect relevant WordPress changes, apply notification rules, format a concise message, and call Slack through its supported API or webhook endpoint. |
How to build a WordPress integration in Martini
Objective
Establish a controlled connection to the target WordPress deployment and confirm the available REST, GraphQL, Media, or webhook mechanisms.
Instructions in Martini
- Identify the site URL, API routes, plugin-provided endpoints, and required resources
- Create a dedicated WordPress integration user with only required capabilities
- Use an Application Password over HTTPS where supported
- Store credentials and endpoint configuration in protected Martini environment settings
Objective
Select an event-driven, API-led, or scheduled trigger based on the WordPress deployment's actual event coverage.
Instructions in Martini
- Use a Martini API or webhook trigger when a supported WordPress event source is available
- Use a scheduler for incremental polling and reconciliation when universal webhooks are unavailable
- Define the object types, statuses, timestamps, and frequency required by the business process
Objective
Read the current WordPress resource or accept an approved payload while preserving enough source information for reliable processing.
Instructions in Martini
- Call the relevant REST or configured GraphQL endpoint
- Handle pagination headers and bounded page sizes
- Use filters such as modified dates, status, author, category, or tag where supported
- Retrieve current resource details after webhook notifications when the event payload is incomplete
Objective
Coordinate the Martini workflow across WordPress, target applications, files, and any intermediate business services.
Instructions in Martini
- Branch by object type, status, publication state, or event type
- Sequence Media uploads before Post or Page associations
- Use reusable workflow logic for shared authentication, mapping, and error handling
- Keep external calls bounded and preserve correlation IDs
Objective
Transform WordPress fields, HTML, taxonomies, IDs, and media references into the target system's canonical model.
Instructions in Martini
- Map Posts, Pages, Media, Users, Comments, and taxonomies explicitly
- Normalize timestamps, statuses, rendered content, and source identifiers
- Validate required fields and account for custom post types or plugin-defined fields
- Preserve external keys and WordPress IDs for idempotent updates
Objective
Apply content, permission, consent, publication, moderation, and routing rules before writing to connected systems.
Instructions in Martini
- Reject or quarantine incomplete or unauthorized content
- Route only approved statuses to publication or downstream systems
- Apply consent and privacy rules before synchronizing Users, comments, or subscribers
- Prevent duplicate creates by checking stored source IDs or external keys
Common WordPress data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Posts | Synchronize blog entries, published content, statuses, authors, categories, tags, and modified timestamps. | Content platforms, search indexes, data warehouses, portals, Salesforce, HubSpot | Martini retrieves Posts incrementally with pagination and filters, maps content and metadata, stores the WordPress ID, and performs idempotent downstream upserts or WordPress updates. |
| Pages | Manage hierarchical website pages and publish approved enterprise content to WordPress. | Enterprise content platforms, portals, search indexes, DAM platforms | Martini maps page hierarchy, status, slug, content, and featured media, validates required fields, and creates or updates Pages through the REST API. |
| Media | Upload, retrieve, classify, and associate images, documents, audio, and video with content. | DAM platforms, cloud storage, content platforms, enterprise portals | Martini transfers files and metadata, preserves MIME type and filenames, records returned Media IDs, and links media to Posts or Pages. |
| Users | Synchronize WordPress account or author information subject to permissions and privacy requirements. | Identity platforms, CRM systems, editorial directories | Martini reads only the fields and users permitted by the endpoint, applies filtering and privacy rules, and avoids treating WordPress Users as a general identity source without site-specific approval. |
| Comments | Route comments for moderation, support processes, notifications, or reporting. | Slack, Jira, moderation platforms, reporting systems | Martini polls or receives deployment-specific notifications, applies moderation rules, maps comment status and author data, and handles duplicate notifications using the comment ID. |
| Categories and tags | Classify Posts and support navigation, search, segmentation, and downstream content taxonomies. | Search platforms, portals, DAM systems, enterprise content platforms | Martini maps taxonomy IDs and names, reconciles changes before content synchronization, and preserves relationships when writing to target systems. |
Authentication and security considerations
Authentication and least privilege
For server-to-server REST integrations, WordPress Application Passwords are generally the clearest core-supported option. They should be used over HTTPS and stored in Martini secrets or protected environment configuration. Cookie authentication with nonces is primarily intended for requests made within an authenticated WordPress session.
- Use a dedicated WordPress integration user rather than a personal administrator account.
- Grant only the roles and capabilities required by the workflows.
- Confirm that the host, proxy, CDN, or security plugin permits the Authorization header.
- Treat OAuth and JWT as deployment- or plugin-specific mechanisms and verify their documentation before use.
Operational considerations for WordPress integrations
Reliability and lifecycle controls
WordPress does not define one universal rate limit. Hosting providers, CDNs, WAFs, security plugins, and WordPress.com plans may impose limits. Use bounded concurrency, pagination, and controlled batch sizes, and respect Retry-After when supplied.
- Retry 429, 5xx, connection, and other transient failures with bounded backoff.
- Use WordPress object IDs, external keys, and checkpoints for idempotency.
- Account for timestamp precision, timezone differences, delayed publication, and missed webhook events.
- Validate HTML, blocks, shortcodes, embeds, custom fields, plugin metadata, MIME types, and media size limits.
- Test against the target site's actual custom post types, routes, permissions, plugins, and schema before production.
- Monitor WordPress, plugin, theme, hosting, and Martini workflow changes for compatibility issues.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable orchestration
Scripts can call WordPress endpoints, but they often leave authentication, pagination, transformation, retries, checkpoints, and operational visibility embedded in application-specific code. Martini provides a workflow-based integration boundary that can be reused across WordPress sites and target systems.
- Centralize REST, GraphQL, Media, and webhook interactions in governed workflows and APIs.
- Separate WordPress schemas from canonical enterprise models through explicit mappings.
- Apply business rules for publication, moderation, consent, routing, and idempotency without duplicating them across scripts.
- Use protected configuration, structured error handling, logs, and monitoring for operational support.
- Expose a stable API façade when downstream systems should not depend directly on WordPress-specific routes.
Frequently asked questions
WordPress can be integrated through its core REST API for Posts, Pages, Media, Users, Comments, taxonomies, and custom routes. Deployments may also provide GraphQL through WPGraphQL, selected webhook notifications through WordPress.com or plugins, REST batch requests, and Media file operations. Scheduled polling is a practical fallback when event coverage is incomplete.
Yes. Martini can consume the WordPress REST API, call configured GraphQL or plugin endpoints, receive webhook requests where the deployment provides them, upload and process Media, and expose APIs for enterprise systems that need to publish or update WordPress content.
No. A dedicated WordPress connector is not required. Martini can use WordPress's confirmed native REST, Media, authentication, batch, and deployment-specific webhook mechanisms, along with configured GraphQL or plugin endpoints where available.
Lonti does not charge an additional per-connector or per-vendor fee to integrate WordPress. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from WordPress, hosting, infrastructure, plugins, or other third-party systems depending on subscriptions, usage, and deployment model.
Use the WordPress REST API for most new integrations because it is part of WordPress core and exposes the primary content and Media resources. Use GraphQL only when WPGraphQL or another extension is installed and its schema is governed. Use batch requests for bounded synchronous operations and deployment-specific webhooks when their event coverage and delivery behavior are confirmed.
Not universally in WordPress core. WordPress.com, plugins, hosting platforms, and custom code can provide notifications for selected events. Martini can receive those requests, but the exact event types, authentication, retries, and delivery guarantees must be verified for the deployment. Scheduled reconciliation is recommended for missed or unsupported changes.
Martini can use scheduled workflows or supported notifications, paginate through REST resources, and filter by modified timestamps, statuses, IDs, or other endpoint parameters. It stores WordPress object IDs, external keys, and checkpoints so retries update existing objects rather than creating duplicate Posts, Pages, or Media.
Yes. Martini can expose a controlled API that accepts enterprise content or workflow requests, validates and transforms them, and then calls WordPress REST or configured plugin endpoints. This can shield downstream systems from WordPress-specific schemas while centralizing authentication, business rules, error handling, and monitoring.
Related Martini documentation
APIs
Transformation
Connect WordPress to your enterprise systems
Use Martini to build governed WordPress integrations around REST APIs, Media resources, deployment-specific events, and reusable workflows.