Welcome to the NZRT Wiki Podcast. Today we’re looking at WordPress Integration.

This episode covers how WordPress and Dolibarr connect inside the NZRT setup, so if you work with either of those systems — or you’re just curious about how the pieces fit together — stick around.

First, a bit of context. NZRT runs two WordPress sites. One is the ICS site — that stands for Internet Consulting Services — and this is the site that actually integrates with Dolibarr. Through that integration, products, clients, and orders managed in Dolibarr can surface on the ICS site. The second site is the NCS site, which handles NZRT Charitable Services, and that one sits completely separately — it doesn’t talk to Dolibarr at all.

So how does the integration actually work? There are two main methods.

The first and primary method is what’s called the Agent REST API approach. AI agents call both the Dolibarr REST API and the WordPress REST API independently, using a set of tools provided by the NZRT MCP server. Think of it as an orchestration layer — Claude or the run-dot-py agents sit in the middle and coordinate cross-system operations. For example, if you need to sync a product from Dolibarr and publish it to WordPress, an agent can handle each side of that through dedicated tools. On the Dolibarr side you have tools for getting and creating products, and on the WordPress side you have tools for creating and updating posts. The Operating Model documentation goes deeper on the MCP server setup if you want to follow up.

The second method is an Obsidian-to-WordPress publishing flow. Vault notes written in Obsidian can be published directly to the ICS WordPress site using the obsidian-wordpress plugin. Simple and straightforward.

Now let’s look at something a bit more technical — the Bridge Plugin and Webhook Trigger setup. This is used specifically for NZRT intake forms, and it enables a direct connection from WordPress straight into Dolibarr. Here’s how that flow works when someone submits a form on the WordPress side.

The form submission triggers an AJAX call that passes through WordPress’s admin handler. That kicks off a function inside a custom plugin called the nzrt-dolibarr-bridge. That function then makes a request to Dolibarr’s REST API, targeting the thirdparties endpoint and passing the API key as a header. Dolibarr receives that, creates the thirdparty record, and internally fires what’s called a company-create action. Now, on the Dolibarr side, there’s a second custom file called the nzrt webhook trigger, sitting inside Dolibarr’s custom triggers folder. It checks whether the company-create action appears in a global setting called WEBHOOK_EVENTS. If it does, it fires off a signed JSON payload to a configured webhook URL, attaching two custom headers — one containing an HMAC-SHA256 signature and one identifying the event type. That signature is what lets the receiving end verify the request is genuine.

Two files make all of this work. The bridge plugin file lives in the 000WOR repository and is deployed to WordPress as a plugin. The webhook trigger file lives in the 000DOL repository and is deployed inside Dolibarr’s custom triggers folder.

To get this running, you also need three configuration constants set up inside Dolibarr — you’ll find these under Setup, then Other, then Constants. There are three of them to know about. The first is WEBHOOK_URL, which is the endpoint Dolibarr will post the event payload to. The second is WEBHOOK_SECRET, which is the signing key used to generate that HMAC-SHA256 signature on outgoing payloads. The third is WEBHOOK_EVENTS, which is a comma-separated list of the action codes you want to trigger webhooks — so for example, you might include both company-create and company-modify if you want events fired for both scenarios.

If you need to set any of this up from scratch, there’s a separate NZRT Integrations document that walks through the deployment steps in detail. And if you’re looking at the broader picture — like what modules are available or how WordPress service codes fit into the NZRT taxonomy — check out the Module List and NZRT WordPress Service Codes docs linked from the related section of this wiki page.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.