Tag Archives: webdav

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, 08 - Reference

Webdav Cheatsheet

Welcome to the NZRT Wiki Podcast. Today we’re looking at WebDAV Cheatsheet.

WebDAV is a protocol that lets you interact with files stored on a server over HTTP. For NZRT, that means you can upload, download, move, copy, and delete files on Nextcloud programmatically, without ever opening a browser. Every operation you’ll see today targets a base endpoint on the Nextcloud server, structured around a path that includes the word “dav”, then “files”, then your username. That username part is important — every command you run needs to be tailored to the account you’re working with.

Let’s start with the basics. To upload a file, you send a PUT request to Nextcloud using curl. You authenticate with your username and password, point curl at the file on your local machine, and specify the destination path on Nextcloud where you want it to land. That’s it — one command, file is uploaded.

Downloading is the reverse. You send a GET-style request with your credentials, provide the remote file path, and tell curl where to save it locally. Simple and reliable.

Now, listing files works a little differently. WebDAV uses a special request type called PROPFIND, which asks the server to return properties about files and folders. You add a header that tells the server you want to look one level deep — so you see the contents of a folder without recursing into subfolders. You also pass a small XML body that asks for file properties. The server responds with an XML document describing everything in that folder.

Deleting a file is straightforward — you send a DELETE request with your credentials and the path to the file. No confirmation prompt, so be deliberate.

Creating a folder uses another WebDAV-specific request type called MKCOL, short for “make collection.” You point it at the path where you want the new folder, authenticate, and Nextcloud creates it.

Copying a file involves a COPY request. You point curl at the source file, and you add a Destination header that specifies where the copy should end up. Both paths need to be full URLs on the server.

Moving or renaming a file works the same way — you use a MOVE request instead, with a Destination header pointing to the new path or new name. One command handles both renaming and relocating.

If you need file metadata — things like content type, file size, last modified date, or an internal file ID — you use PROPFIND again, but this time against a specific file rather than a folder, and you pass a more detailed XML body listing exactly which properties you want back.

Now for the more powerful stuff. There’s a bulk upload script that loops through all PDF files in your current directory and uploads each one to a specific remote folder on Nextcloud. You set four variables at the top: the server URL, your username, your password, and the remote path — in the example that’s a Finance invoices folder for April 2026. The script then iterates over every PDF it finds and fires off a PUT request for each one, printing a confirmation line after each upload.

The bulk download script does the opposite. It first runs a PROPFIND to list files in a remote folder, extracts the file paths from the XML response, then loops through them and downloads each one to your current local directory.

You can also mount Nextcloud as a drive on Linux. You install a package called davfs2, then run a mount command pointing at the WebDAV URL, specifying a local mount point and your username. You’ll be prompted for your password. Once mounted, you interact with Nextcloud files exactly like a local folder. To disconnect, you run the unmount command.

On Windows, it’s even simpler. Open File Explorer, choose Map Network Drive, paste in the WebDAV URL with your username at the end, check the option to connect with different credentials, and enter your Nextcloud username and password. Nextcloud appears as a mapped drive in Explorer.

There’s also a practical NZRT example in the cheatsheet — a nightly invoice sync. This script queries the Dolibarr database for invoices created in the last day, then uploads each matching PDF from the local Dolibarr invoices folder to Nextcloud under the Finance invoices path. This is the kind of automation WebDAV was built for: bridging your ERP system and your file server without any manual steps.

To put it in context for NZRT — WebDAV is the glue that connects Nextcloud to your other systems. Whether you’re syncing Dolibarr invoices, running nightly backups, or building integrations with third-party tools, WebDAV gives you a consistent, scriptable interface to your Nextcloud storage. Related topics worth reading alongside this one include the REST API and WebDAV overview, the Nextcloud CLI Cheatsheet, and the Dolibarr Integration notes.

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