Category Archives: 05 – Integrations

000NCL, 05 - Integrations

Dolibarr Integration

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

So let’s start with the big picture. Nextcloud and Dolibarr work together through a REST API connection combined with file sync. The goal is to let Dolibarr’s EDM module — that stands for Electronic Document Management — store its documents inside Nextcloud. By doing that, you get all of Nextcloud’s strengths: version history, sharing capabilities, and long-term archival, all feeding into the same documents your ERP system is working with.

Now let’s walk through what actually happens when you create an invoice. The workflow goes like this. First, you create an invoice inside Dolibarr. As soon as that happens, the system automatically saves a PDF copy of that invoice into a specific folder path in Nextcloud — something like Finance, then Invoices, then the year and month, then the invoice filename itself. Dolibarr then records that Nextcloud file path in its own database, so it always knows where the live copy lives. From that point on, you or your colleagues can open, version, or share that invoice directly inside Nextcloud, while Dolibarr keeps pointing to the same file. One document, two systems, no duplication of effort.

Let’s talk about the REST API side of things. There are two key calls that make this work. The first one handles authentication — it sends a request to Nextcloud asking for an access token, passing along a client ID and client secret. Think of it like knocking on the door and showing your credentials before you’re allowed in. The second call actually uploads a file. It uses a PUT request — that’s the web method for placing something at a specific location — and it sends the PDF file to a particular user’s folder path inside Nextcloud. The user and password are passed along with the request so Nextcloud knows who’s doing the uploading. That’s the core of how files move from Dolibarr into Nextcloud programmatically.

Now let’s look at how those files are organised once they’re in Nextcloud. There’s a top-level shared folder, and inside it sits a folder called Dolibarr EDM. Under that, you’ve got three main subfolders. The first is Invoices, which is further broken down by year and month — so April 2026 would have its own subfolder containing individual invoice PDFs like INV-001 and INV-002. The second subfolder is Contracts, which is organised by client — so Client A gets their own folder holding their contract and any amendments. The third subfolder is Purchase Orders, where PO files live in a flat structure by year and reference number. Clean, predictable, and easy to navigate.

Now here’s where the automation really shines — the nightly sync workflow. Every night at two in the morning, a scheduled process kicks off a five-step routine. Step one: it queries the Dolibarr API to find any documents that are new or have been updated since the last run. Step two: it checks Nextcloud to see if any of those documents already exist, so nothing gets duplicated. Step three: any files that are missing from Nextcloud get uploaded. Step four: Dolibarr’s file path references get updated to reflect the current locations. Step five: any documents older than ninety days get moved off to a NAS — a network-attached storage system — for long-term archiving. And at the end of all that, an email report goes out to the Finance role and the EDM role so the right people know what happened overnight. The whole thing runs without anyone needing to touch it.

Finally, a word on how this fits into NZRT specifically. This Nextcloud and Dolibarr connection is described as the backbone of NZRT’s document management. Three roles interact with it most closely. Finance, referred to internally as fin, handles invoices. The EDM role, referred to as ema, manages the document flows. And the Admin role, xc, oversees the whole thing. All three roles collaborate on invoices, contracts, and purchase orders through this single integrated system — so there’s one source of truth rather than files scattered across different tools.

If you want to dig deeper, there are three related wiki pages worth checking out: the Integrations Overview, the REST API and WebDAV guide, and the Document Management Overview. Those will give you more context on the broader architecture this integration sits within.

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

000NCL, 05 - Integrations

Integrations Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Integrations Overview.

If you’ve ever wondered how Nextcloud fits into the broader NZRT tech stack, this is the episode for you. Nextcloud doesn’t just sit on its own — it connects to a whole range of other systems, and today we’re going to walk you through what those connections are, how they work, and why they matter.

Let’s start with the big picture. Nextcloud integrates with four main categories of systems: Dolibarr, which is our ERP platform; WordPress, our content management system; email systems for calendar and contact syncing; and external storage like network-attached storage devices for backup and archiving. On top of those, you can also build custom integrations using Nextcloud’s REST API and webhook support.

Now let’s talk about the integration types in a bit more detail. There are five main ones to know about.

First, the Dolibarr integration. This uses a combination of REST API calls and file synchronisation. The main use case here is electronic document management — what we often call EDM — along with document versioning. So when documents are created or updated in Dolibarr, they can flow into Nextcloud and be properly version-controlled.

Second, the WordPress integration. This also uses the REST API, plus LDAP for directory services. The use cases are user synchronisation — so your user accounts stay consistent across both platforms — and media asset management.

Third, email integration. This one uses the CalDAV and CardDAV protocols. If those sound unfamiliar, think of CalDAV as the standard way calendar data is shared over the internet, and CardDAV as the same idea but for contact information. So through this integration, your calendar events and contacts can stay in sync between Nextcloud and your email system.

Fourth, external NAS integration. NAS stands for Network-Attached Storage — basically a dedicated file server on your network. Nextcloud connects to these using SMB or NFS protocols, which are standard network file-sharing protocols. The use case is backup and archive storage, so older or less-accessed data can be offloaded to external storage while still being reachable through Nextcloud.

Fifth and finally, custom app integrations. These use the REST API combined with webhooks. Webhooks are a way for one system to notify another in real time when something happens — think of them as event triggers. This category is for building your own automation workflows on top of Nextcloud.

Now let’s look at how all of this fits together architecturally. The code block in the wiki shows a hub-and-spoke diagram. Picture Nextcloud at the centre. Radiating out from that hub, you have five connections. Dolibarr sits on one branch, handling ERP data and electronic document management. WordPress is on another, covering user sync and media. Email connects for calendar and contacts. External NAS branches off for archive backup. And custom webhooks extend outward for workflow automation. Nextcloud is the connective tissue holding all of these systems together.

So how does authentication work across all these integrations? There are four methods you might encounter. The first is LDAP and single sign-on, which gives you a unified user directory — one set of credentials that works across systems. The second is API tokens, used by service accounts for automated processes. If a script or agent needs to talk to Nextcloud without a human logging in, it uses a token. The third is OAuth2, the standard for letting third-party apps authenticate securely without exposing passwords. And the fourth is basic authentication — plain username and password — which is considered a legacy approach and is not recommended for new integrations.

Why does all of this matter for NZRT specifically? The core goal is eliminating data silos. Without these integrations, documents in Dolibarr wouldn’t talk to storage in Nextcloud, and media in WordPress would be disconnected from everything else. With these connections in place, an invoice generated in Dolibarr can be stored and versioned in Nextcloud. Media assets in WordPress can be sourced directly from Nextcloud. And custom automation via the API and WebDAV layer means your EDM workflows can be built to fit exactly how NZRT operates, rather than forcing you to work around the tools.

If you want to go deeper, the related docs to look up are the Dolibarr Integration note, the WordPress Integration note, the Email and CalDAV CardDAV note, and the REST API and WebDAV note. Each of those covers the specifics of how those individual connections are configured and maintained.

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

000NCL, 05 - Integrations

Rest Api Webdav

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud REST API and WebDAV.

Nextcloud gives you two different ways to interact with it programmatically. The first is WebDAV, which stands for Web Distributed Authoring and Versioning. The second is a REST API. Both of these let you automate tasks, integrate third-party tools, and perform bulk operations without ever having to touch the web interface manually. Let’s walk through what each one does and how you’d actually use them.

Starting with WebDAV. This is the protocol you use for file operations — uploading, downloading, listing, and deleting files. Every WebDAV request you make goes to a base URL on your Nextcloud server, followed by a path that includes the username of the account you’re working with and then the folder path inside that account.

So, uploading a file — let’s say a PDF into a Finance folder — you’d make a PUT request, authenticate with a username and password, and point it at the exact path where you want the file to land. Nextcloud places it right there.

Downloading works the opposite way. You make a standard GET request to that same file path, authenticate, and tell your tool where to save the output locally. The file comes back to you.

Listing the contents of a folder is a little different. WebDAV uses a special request type called PROPFIND for this. You point it at a folder path, include a small XML body that tells Nextcloud you want the properties of everything inside, and it returns an XML response with details about every file and subfolder in that location.

Deleting a file is the simplest of all — a DELETE request to the file’s path, with your credentials, and it’s gone.

Now let’s move on to the REST API side of things. This is what you use for user management, sharing, and app-level operations. These requests go to a different base endpoint — the OCS API path on your Nextcloud server.

Creating a new user requires admin credentials. You send a POST request, include a special header that tells Nextcloud this is an API request rather than a browser session, and pass the new username and a temporary password. That’s it — the account exists.

Adding a user to a group follows a similar pattern. Another POST request, again with admin credentials and that same API header, but this time you target a URL that includes the username you want to update, and you pass the group name you want to add them to.

If you want to list all the shares belonging to a particular user, you send a GET request to the file-sharing endpoint with that user’s credentials and the API header. You get back a list of everything they’ve shared.

Creating a share link — the kind where anyone with the link can access a file — is also a POST request to the file-sharing endpoint. You pass the file path, a share type value of three which means public link, and a permissions value of one which means read-only. Nextcloud returns a share URL you can distribute.

Now, a quick note on authentication. There are three ways to authenticate with Nextcloud. The first is basic auth, which is just a username and password combination. This works well for development and scripting but isn’t ideal for production. The second is app tokens — these are long strings you generate inside Nextcloud and use in place of your actual password. They’re more secure and the right choice for production automation. The third is OAuth2, which is the three-step flow you’d use for integrating third-party applications that need to act on behalf of a user.

Let’s look at how NZRT actually uses these capabilities in practice. There are two main automation examples worth knowing about.

The first is a nightly invoice sync. This script queries the Dolibarr database for any invoices created in the last day, then loops through each one and uploads the corresponding PDF file into a Finance folder on Nextcloud under the ema account. This runs automatically each night, keeping Nextcloud in sync with what Dolibarr knows about.

The second is bulk user provisioning. This script reads from a CSV file — a spreadsheet with columns for name, email, and role. For each row, it makes two API calls. The first creates the user account in Nextcloud. The second adds that user to the appropriate group based on their role. So you could spin up ten new user accounts in the time it takes to run a single script.

In terms of which NZRT agents use these capabilities — dan, who handles database and backend work, uses this for automating backups and bulk provisioning. Dai, the data agent, uses the API for extracting reports and making analytics calls. And ema, who handles document and records management, uses WebDAV to sync documents from Dolibarr and run archiving workflows.

If you want to dig deeper, the related wiki articles on Integrations Overview, Dolibarr Integration, and the Nextcloud CLI Cheatsheet are good next steps.

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

000NCL, 05 - Integrations

WordPress Integration

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

If you work with NZRT’s content or user management systems, this episode is going to give you a clear picture of how Nextcloud and WordPress talk to each other — and why that connection matters for your day-to-day work.

Let’s start with the big picture. Nextcloud and WordPress are integrated across three main areas: user authentication, media asset storage, and collaborative content editing. Nextcloud acts as the media library backend for WordPress, meaning it’s the central place where files live, and WordPress pulls from it rather than managing everything on its own.

Let’s talk about user sync first. NZRT uses something called LDAP and single sign-on, or SSO, to connect accounts between the two systems. What that means for you practically is this: when a new Nextcloud user is created, a corresponding WordPress user gets created automatically. And you only need one password for both platforms. You log in once and you’re covered across both systems — no separate credentials to manage.

Now let’s look at media management. WordPress media assets — things like images, photos, and press release files — are stored in Nextcloud rather than sitting inside WordPress itself. This happens through the REST API, which is essentially a way for the two systems to communicate and pass data back and forth. The specific folder in Nextcloud that handles this is called WordPress Media, and it’s shared with the content team. Featured images and uploads get automatically backed up there too, so you have version control and an archive without any extra effort on your part.

To give you a sense of how the technical side is configured, there is a setup that points the WordPress LDAP plugin to an internal server address, specifies a base directory location for user accounts, and sets a user path within that directory. On the Nextcloud side, there is an API endpoint pointing to the WordPress Media folder, using a combination of a username and a token to verify access. You do not need to memorise any of that, but it is worth knowing these two systems are talking to each other constantly in the background.

Now let’s walk through the actual content workflow, because this is what you will interact with most. An editor logs into WordPress using their normal single sign-on credentials. From there, an author writes a blog post inside WordPress. But here is where Nextcloud steps in: draft documents live in a Nextcloud folder called WordPress Drafts, and the team can edit those directly using Nextcloud Office, the built-in collaborative editing tool. Once a post is ready to publish, the featured image auto-syncs from the Nextcloud media folder into WordPress. And when the post goes live, a version is saved into a Nextcloud archive folder for long-term storage.

So you can think of it as a two-track system. WordPress is your publishing front-end — it is where the post goes live and where readers see it. Nextcloud is your back-end storage and collaboration layer — it is where files live, where the team edits together, and where everything gets archived.

Speaking of folders, here is how the Nextcloud WordPress directory is structured. At the top level there is a folder called WordPress. Inside that you have a Media folder, which contains three subfolders — one for Blog images, one for Press Releases, and one for Photos. Then there is a Drafts folder, where you would find documents like a named blog post file for a specific month. And finally there is a Published Archive folder, where completed posts are stored for reference.

The key people working within this integration at NZRT are pam and ema — the content team — who use Nextcloud Office to collaborate on blog posts before they go live. By keeping media assets in Nextcloud rather than relying on WordPress alone, the team gets version control, easy sharing, and a reliable archive all in one place.

If you want to dig deeper, there are a few related topics worth exploring. There is an Integrations Overview document that gives you the wider picture of how NZRT’s systems connect. There is also a dedicated page on LDAP and SSO if you want to understand the authentication side in more detail. And Nextcloud Office is worth a look if you are going to be collaborating on drafts.

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