Development workflow Intro
The REST API you already have
You are already using it even if you never go headless — this is how the block editor saves your posts. Knowing the response shape halves your client…
Technote
The REST API and going headless
Using WordPress as a data source, and where that stops working — endpoint design, authentication, caching and security, in build order.
8 articles
Development workflow Intro
Exposing a post type and its meta with show_in_rest
A post type opens with one line. Meta does not: it needs a registered type, an auth_callback governs writing, and reading opens regardless.
Development workflow Practical
Your own endpoint: namespace, permission callback, schema
permission_callback is not optional. Omit it and the route is public, with a core warning to match. An args schema then keeps validation out of your handler entirely.
Security Practical
Choosing authentication: cookies, application passwords, tokens
These three differ in threat model, not convenience. Whether the caller is a browser, your own server, or a third party decides the answer for you.
Security Practical
Receiving webhooks: a nonce check fails every time
An external server has no cookie and no nonce. Verify by signature or shared key, compare with hash_equals, and always sign the raw body.
Security Practical
Closing user enumeration: what REST hands out by default
/wp-json/wp/v2/users opens without login, and the slug it carries is usually the username. That leaves an attacker with only the password to find.
Performance optimization Advanced
Caching API responses: which layer, and how to invalidate
Adding a cache is easy. Knowing when to discard it is the work — and getting that wrong can end with payment state that never updates.
Development workflow Advanced
The price of headless: preview, editing and operations
Headless is not a free upgrade. The gains are real and so are the losses — and the most underestimated of them is preview.