Welcome to the NZRT Wiki Podcast. Today we’re looking at 🔌 WordPress REST API.

So what is the WordPress REST API? Put simply, it’s a way for other software to talk to your WordPress site using standard web requests. Instead of logging into a dashboard and clicking around, you can send a request to a specific web address and get data back in a format called JSON — which is just structured text that machines are very good at reading. Plugins, mobile apps, and external services all use this approach to read and write things like posts, users, and custom data.

Let’s talk about the basic building blocks. There are five core actions you’ll use constantly. First, you can fetch a list of all your posts by hitting the posts endpoint on your site’s API path. Second, if you want just one specific post, you add its ID to the end of that same address. Those two are read-only, so no credentials needed. But the next three — creating a new post, updating an existing one, or deleting one — all require you to be authenticated first. WordPress won’t let just anyone write or delete content through the API, which makes sense.

Speaking of authentication, how do you prove who you are? The most common approach at NZRT is application passwords. Think of it like a special one-time key you generate in your WordPress user profile — separate from your main login password. When you make a request, you pass your username and that application password together. There’s a command-line example that shows this in action: you send a request to the users endpoint asking for your own profile, and you pass your credentials alongside it. If everything checks out, WordPress returns your user data as JSON. OAuth2 is another option if you’re building something more complex that needs delegated access.

Now here’s where things get really powerful — custom endpoints. WordPress lets you register your own API routes, not just the built-in ones for posts and pages. There’s a PHP snippet that shows exactly how this works. You hook into WordPress at the point where the REST API is being set up, then you declare a new route — in this example it lives under a namespace called myapp version one, and the path is slash data. You tell WordPress it should respond to GET requests, point it to a callback function that actually handles the logic, and set a permission callback. In this case the permission is set to always return true, meaning anyone can call it — though in a real-world scenario you’d want to lock that down based on user roles.

So why does all of this matter at NZRT specifically? Your WP-Script plugin is the practical answer. It uses the WordPress REST API as a bridge between WordPress and Dolibarr — your ERP system. When data changes in Dolibarr, whether that’s customer records, invoices, or HR data, WP-Script can pull that through via REST API calls and keep things in sync. External integrations also rely on this same mechanism for data exchange, so anything talking to your WordPress site from the outside is almost certainly going through these endpoints.

If you want to dig deeper, check out the related notes on WordPress Overview, WP-Script Core, and Dolibarr REST API Setup — they’ll give you the full picture of how these pieces connect.

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