Case Studies EndPointy Menus: WordPress menus over a REST API
EndPointy Menus: WordPress menus over a REST API
TL;DR Headless WordPress exposes posts over the REST API, but not menus, so decoupled front ends cannot read the navigation editors set in wp-admin. EndPointy Menus adds a REST endpoint for menus, so a separate front end can fetch and render them without a workaround.
Headless WordPress is a great setup: keep the editor people know, render the front end however you like. But it has an annoying gap. The REST API gives you posts and pages, and then leaves you stranded on menus, the one thing editors expect to control. EndPointy Menus fills that gap.
The problem
In a decoupled build, WordPress is the backend and a separate app renders the site by reading the REST API. Posts, pages, and custom types come across fine. Navigation menus do not have a clean, standard endpoint.
That leaves two bad options. Hardcode the navigation in the front end, which takes control away from the editors who are supposed to manage the site. Or cobble together a custom endpoint by hand for every project, reinventing the same thing each time.
Neither is right. Editors should manage menus in wp-admin, and the front end should just read them.
The approach
Expose menus the way the rest of the content is exposed.
- A REST endpoint for menus, so a decoupled front end can fetch the navigation with a normal API call.
- Editors keep control. They arrange menus in wp-admin as always, and the front end reflects whatever they set.
It restores the normal division of labour that headless otherwise breaks: content people manage navigation, developers just render it.
What shipped
EndPointy Menus exposes WordPress menus through a REST API endpoint for headless and decoupled applications. A separate front end can fetch the site's navigation and render it, while editors keep managing menus in the admin they already know. No hardcoding, no per-project custom endpoint.
What I learned building it
The lesson was that headless WordPress lives or dies on the gaps. The happy path, reading posts, is well trodden; the value is in the missing pieces that break the editor-driven workflow. Menus are a small thing until you are building headless and realise the people running the site can no longer touch the navigation. Closing that kind of gap is what makes decoupled WordPress actually usable.
EndPointy Menus is one of my WordPress plugins. The full set is in the products section of the site.
FAQ
Why are WordPress menus not in the REST API by default?
The core REST API exposes content like posts and pages, but menus were historically managed separately and not surfaced as a clean endpoint. So a headless front end that wants the site navigation has nothing standard to call, which is the gap this plugin fills.
What is headless WordPress?
It means using WordPress only as the content backend, edited in wp-admin, while a separate application, often in React or another framework, renders the front end by reading WordPress over its API. It keeps the familiar editor while freeing the front end.
Why expose menus rather than hardcode navigation?
So editors keep control. If navigation is hardcoded in the front end, changing it needs a developer. Exposing the WordPress menu over an endpoint lets the people who manage the site edit navigation in wp-admin, and the front end just reflects it.