AI coding tools are good at repeating a clear pattern. They are much less reliable when a backend exposes several generations of authentication, inconsistent route names, or undocumented response shapes.
JSON API User Plus 5.0.4 gives AI builders a compact path to follow: discover the controller, call userplus/login, store the returned JWT, send it as a Bearer token, and build profile or content features on top. Claude, Codex, Gemini, Copilot, and similar tools can all work with this contract because it looks like a conventional mobile API rather than a WordPress browser session.
Start with discovery, not assumptions
Give the agent a base URL and ask it to inspect:
GET https://example.com/api/userplus/info/
User Plus 5.0.4 reports its version, auth: jwt, removed legacy endpoints, and active controller names. If BuddyPress features are in scope, also inspect:
GET https://example.com/api/buddypress/info/
For dynamic content models, use:
GET /api/postsplus/get_post_types/
GET /api/postsplus/get_taxonomies/?post_type=listing
Discovery prevents an agent from inventing /wp-json/... routes, cookie nonces, or legacy User Plus methods that are not part of this plugin.
Give the AI a source-of-truth contract
A short project note is more useful than a vague “add WordPress login” prompt:
Backend: JSON API User Plus 5.0.4 Base API: https://example.com/api Auth: JWT Bearer only; HTTPS required Login: POST /userplus/login/ with username or email + password Token response field: token (not access_token) Session check: GET /userplus/validate_token/ with Authorization header Private profile: GET /userplus/me/ Protected header: Authorization: Bearer <token> Secure storage: Keychain/Keystore-backed only On 401: clear token and private cache, then return to login Never log credentials or tokens
The token detail matters. Generic OAuth examples often expect access_token, while the actual v5.0.4 controller returns token.
Ask for one vertical slice first
The best first generation is not an entire app. Ask for a testable vertical slice:
- A typed User Plus API client.
- A login form with loading and error states.
- Secure token storage.
- Session validation on startup.
- A profile screen populated from
userplus/me. - Logout that clears the token and private data.
- Unit tests for parsing, 401 handling, and redacted logs.
Once this slice works against a staging WordPress site, reuse its authenticated client for profile updates, meta, SSO, PostsPlus, or BuddyPress.
A prompt that produces better code
Implement a production-oriented Flutter authentication slice for JSON API User Plus 5.0.4.
Use POST {baseUrl}/api/userplus/login/ with form fields username and password. Parse the JWT from response.token. Store it only with a Keychain/Keystore-backed secure-storage adapter. Send it on protected calls as Authorization: Bearer <token>.
On startup, call GET /api/userplus/validate_token/. Route to Home only when valid is true. On HTTP 401 or valid=false, delete the token, clear private cached profile data, and route to Login.
Create separate transport, repository, session controller, and UI layers. Model loading, invalid credentials, timeout, offline, server error, and malformed JSON states. Never print passwords, JWTs, or full Authorization headers. Add unit tests with mocked HTTP responses. Do not invent refresh-token behavior; this API response does not provide a refresh token.
This prompt defines behavior and boundaries without forcing the model to reproduce your whole architecture.
Endpoint patterns an agent can reuse
User Plus’s naming is easy to map into tools or generated services:
| Goal | Method and path | Authentication |
|---|---|---|
| Discover User Plus | GET /userplus/info/ |
Public |
| Log in | POST /userplus/login/ |
Public credentials |
| Register | POST /userplus/register/ or /signup/ |
Public, if WordPress registration is open |
| Validate session | GET /userplus/validate_token/ |
Bearer JWT |
| Read own profile | GET /userplus/me/ |
Bearer JWT |
| Update own profile | POST /userplus/update_user/ |
Bearer JWT |
| Read own meta | GET /userplus/meta/ |
Bearer JWT |
| Write many meta keys | POST /userplus/set_meta_many/ |
Bearer JWT |
| Delete account | POST /userplus/delete_account/ |
Bearer JWT |
An AI can convert this table into a Dart service, Swift protocol, Kotlin interface, TypeScript client, OpenAPI draft, test fixtures, or an integration checklist.
Keep generated code honest
Require evidence for every backend assumption. A useful review prompt is:
Audit this client against the supplied User Plus endpoint table. List every path, method, request field, response field, and authentication assumption. Flag anything not supported by the contract. Confirm that no token reaches logs, URLs, analytics, or ordinary preferences.
Watch for these common hallucinations:
- Using WordPress cookies or nonce authentication.
- Calling
/wp-json/wp/v2for User Plus endpoints. - Reading
access_tokeninstead oftoken. - Inventing refresh tokens or a refresh endpoint.
- Sending a token in a query string.
- Treating any HTTP 200 body as authenticated without checking its fields.
- Assuming JWT authentication grants every WordPress capability.
- Storing the token in plain shared preferences.
Add profile and meta flows
Once authentication works, ask the tool to extend the same repository. For profile edits, use update_user; for app-specific preferences, use set_meta_many with a custom_fields or meta object.
Keep a server-approved list of keys. User Plus blocks sensitive WordPress keys, but generated clients should not become arbitrary meta editors.
Example request shape:
POST /api/userplus/set_meta_many/ Authorization: Bearer <token> custom_fields[preferred_language]=en custom_fields[onboarding_complete]=yes
Use AI for tests as aggressively as UI
Ask the agent to generate fixtures for:
- Successful login and the exact
tokenresponse. - 401 invalid credentials.
- Token validation returning
valid: false. - Expired JWT during a protected call.
- Offline startup with an existing token.
- Malformed JSON and missing
userfields. - Concurrent requests after session expiry.
- Logout while a request is in flight.
Tests are where a machine-generated integration becomes maintainable. They also make future plugin or client upgrades safer.
Do not give an AI unnecessary secrets
Use a staging account with the minimum role. Keep production passwords, JWT signing material, Apple private keys, Facebook app secrets, database credentials, and license keys out of prompts and repositories. Provide redacted fixtures and environment-variable names.
If an agent can execute requests, scope its network access and credentials to the staging API. Review destructive operations such as post deletion or delete_account before allowing live execution.
A repeatable AI workflow
The reliable sequence is simple: discover, document, generate one vertical slice, test it against staging, audit assumptions, and only then extend. User Plus’s endpoint families give AI builders the regularity they need, while WordPress capabilities and server-side validation remain the authority that generated code cannot replace.
