REST API

Reign registers a small, focused REST namespace: /wp-json/reign/v1/. It exists to fill specific gaps in WordPress core’s own REST API for end-user-facing theme features, not to replace it. Everything here works on a standalone WordPress install, with no BuddyPress or WooCommerce dependency.

Routes are registered on rest_api_init from inc/REST/Component.php, which boots four controllers: Auth, Nonces, Preferences and Info.

Authentication routes

POST /wp-json/reign/v1/auth/signup

Public, gated by the users_can_register option, the same setting the standard wp-login.php registration form respects. Fills a real gap: core’s POST /wp/v2/users requires the create_users capability, so it cannot be used for public self-registration.

Parameters: user_login and user_email (required), user_pass (optional; when omitted a random password is generated and emailed to the new user), first_name and last_name (optional). Returns the new user_id and user_login on success, or a 409 if the username or email is already taken.

Fires reign_rest_after_signup( int $user_id, WP_REST_Request $request ) after a successful signup, for plugins that want to react, such as creating a BuddyPress activity entry or a CRM contact.

POST /wp-json/reign/v1/auth/magic-link

Public. Emails a one-time sign-in link for a given email parameter, which accepts either an email address or a username. When iThemes Security’s Passwordless Login is active, the request delegates to it; otherwise it falls back to a standard WordPress password-reset key URL. The response is identical whether or not an account exists for the given identifier, to avoid leaking which emails are registered.

Why there is no /auth/signin

WordPress’s canonical login flow is wp-login.php, an HTML form post, not REST. Reign’s own sign-in form already submits through that same flow via admin-ajax.php, which is what lets security plugins such as iThemes Security, Wordfence and Loginizer hook into the request to apply two-factor challenges, brute-force throttling and lockout policies. A REST endpoint that called wp_signon() directly would bypass all of that, so Reign does not ship one. For programmatic login from another application, use WordPress core’s own Application Passwords instead.

Cache-safe nonce refresh

GET /wp-json/reign/v1/nonces

Logged-in only. Returns the per-user nonces (reign_login_nonce, reign_friendship_nonce, reign_notification_nonce, reign_message_nonce, and a generic rest_nonce) that used to be baked into cached HTML. Fetching them separately, after the cached page has already loaded, means the page itself can be served from a full-page cache for every visitor. Response sends Cache-Control: no-store, private.

User preferences

GET / POST /wp-json/reign/v1/preferences/color-mode

Both logged-in only. GET returns the visitor’s saved colour-mode preference (light, dark or auto), falling back to the Customizer’s site-wide default when the visitor has not set a personal one. POST saves a new preference; body is { "mode": "light" } (or dark / auto), stored in user meta so the choice follows the visitor between devices, rather than staying in localStorage only. GET responses send Cache-Control: private, max-age=300.

Theme info

GET /wp-json/reign/v1/info

Public. Returns the theme name, version and text domain, plus a small feature map (whether the dark-mode toggle is enabled, the active style variation, the default colour mode) and an integration map showing which of BuddyPress, WooCommerce, bbPress, LearnDash and Easy Digital Downloads are active. Useful for other plugin code that needs to detect Reign without parsing the stylesheet header itself. Cacheable at the edge: Cache-Control: public, max-age=300.

What this surface deliberately does not cover

This is a small, internal-facing API, not a general content API. It has no routes for posts, pages, or BuddyPress data. WordPress core’s own /wp/v2/ namespace and the BuddyPress REST API already cover that ground, and Reign does not duplicate it.

The pre-existing admin-ajax.php handlers for sign-in, sign-up and the magic-link email continue to work unchanged. The REST routes are an additional path for code written against fetch() or wp.apiFetch, not a replacement for the AJAX handlers, and the sign-in flow specifically stays on admin-ajax.php for the security-plugin-compatibility reason explained above.