Simple JWT Login v4

Register user response shape changed

POST /users used to return {"success":true,"ID":1,...}. It now returns {"success":true,"data":{"id":1,...}}. The user object is nested under "data", "ID" is lowercase "id", and several fields were renamed: user_login → login, user_nicename → nicename, user_email → email, user_url → url, user_registered → registered, user_activation_key → activation_key, user_status → status.

Action: Update any code that reads user fields from the register response - check both the new nesting under "data" and the renamed field keys.

Legacy /register endpoint removed

The old POST /simple-jwt-login/v1/register route no longer exists. The canonical route is POST /simple-jwt-login/v1/users.

Action: Update all callers to use POST /simple-jwt-login/v1/users.

User Identification moved to General settings

The "User Identification" option (email, login, ID) has moved from the Delete User settings tab to the General settings tab. It now applies globally to all endpoints.

Action: After upgrading, verify the User Identification value in Settings → Simple JWT Login → General.

Settings storage structure reorganized

The internal layout of plugin options in wp_options has changed. Existing settings are migrated automatically on first load, but the old keys are removed.

Action: Review every settings tab after upgrading to confirm values carried over correctly.

Authentication response now includes refresh_token

POST /auth returns a new "refresh_token" field when the refresh token feature is enabled. The JWT field itself is unchanged.

Action: No action needed unless your client strictly rejects unexpected response fields or you need to store the token.

2FA changes the /auth flow for affected users

Users with the Two Factor plugin configured now receive a short-lived interim JWT from /auth instead of a full JWT. A second request to POST /auth/2fa (with the interim JWT + 2FA code) is required to get the real token.

Action: Update your authentication flow to handle the interim JWT case, or leave 2FA disabled for API users.

Error response envelope: message and error_code moved under data

In v3, error responses had the form {"success":false,"message":"...","error_code":N}. In v4, both fields moved under a nested data object: {"success":false,"data":{"message":"...","error_code":N}}. Every endpoint follows this new shape.

Action: Update all error-handling code to read response.data.message and response.data.error_code instead of response.message and response.error_code.

Protected endpoint auth failures return 401 instead of 403

When the Protect Endpoint feature blocks an unauthenticated request, the plugin previously returned HTTP 403 Forbidden. It now returns HTTP 401 Unauthorized to align with the HTTP spec.

Action: Update any code that checks specifically for status 403 on protected routes to handle 401 instead.

Error field renamed: errorCode → error_code

In v3, the error field in responses was named "errorCode" (camelCase). In v4, it is renamed to "error_code" (snake_case) to match the rest of the API's naming convention.

Action: Update all error-handling code that reads response.errorCode (or response.data.errorCode) to use error_code instead.