Many WordPress apps need more than blog posts. A property app has listings, cities, prices, and amenities. An events app has venues, dates, speakers, and tracks. A directory has businesses, regions, and service categories.
PostsPlus, included with JSON API User Plus 5.0.4, exposes those structures through its own postsplus/* namespace. It can discover public post types and taxonomies, read content, create or update CPT entries, assign terms, manage post meta, and attach media.
Why PostsPlus is separate
RESTful JSON API Pro remains the authoritative owner of its posts/* controller. User Plus puts its content API under postsplus/*, so both plugins can run on the same site without route or controller collisions.
This separation makes client intent explicit:
/api/posts/...belongs to the Pro content controller./api/postsplus/...belongs to User Plus’s content controller./api/userplus/...handles accounts, profiles, meta, and SSO.
Do not mix endpoint families accidentally. Pick the controller contract your app supports and keep its models and tests together.
Discover the content model
Avoid hard-coding a CPT map when your app can discover it:
curl "https://example.com/api/postsplus/get_post_types/" curl "https://example.com/api/postsplus/get_taxonomies/?post_type=listing" curl "https://example.com/api/postsplus/get_terms/?taxonomy=property_city&hide_empty=0"
get_post_types returns public types and their associated taxonomies. get_taxonomies can be filtered by post_type. get_terms supports taxonomy discovery with count and offset options.
Cache this relatively stable schema locally, but offer a refresh path so a newly registered CPT or taxonomy does not require an app release.
Read CPT entries
PostsPlus provides public read endpoints including get_posts, get_post, recent/date/category/tag/author queries, taxonomy-post queries, terms, media, attachments, and comments.
For example:
curl "https://example.com/api/postsplus/get_posts/?post_type=listing&count=20&page=1" curl "https://example.com/api/postsplus/get_taxonomy_posts/?taxonomy=property_city&term=lahore&post_type=listing&count=20&page=1" curl "https://example.com/api/postsplus/get_post/?id=123"
Public reads do not require a JWT. Whether a post appears still depends on its status and the WordPress query behavior. Keep drafts and private workflow data behind authenticated editorial screens.
Create a CPT entry with taxonomy and meta
Writes require a User Plus JWT and the corresponding WordPress capability. For a CPT named listing, the authenticated role must have its create/edit capability. The token proves identity; WordPress capabilities decide authorization.
curl -X POST "https://example.com/api/postsplus/create_post/" \ -H "Authorization: Bearer eyJ..." \ -d "post_type=listing" \ -d "status=draft" \ -d "title=Canal View Apartment" \ -d "content=Two-bedroom apartment with covered parking." \ -d "taxonomies[property_city][]=lahore" \ -d "taxonomies[property_type][]=apartment" \ -d "meta[price]=27500000" \ -d "meta[bedrooms]=2" \ -d "meta[featured]=yes"
The response includes the created post and any attachments_added.
The meta[field_name] request shape is “ACF-style” in the app-integration sense: it lets a client send named custom fields in the same write. PostsPlus stores them with WordPress post_meta. It does not replace ACF’s field definitions, validation, formatting, repeaters, or relationship logic. If an ACF field expects a particular stored representation, your API payload must match it, or server-side code should translate and validate it.
Update only what changed
curl -X POST "https://example.com/api/postsplus/update_post/" \ -H "Authorization: Bearer eyJ..." \ -d "id=123" \ -d "title=Canal View Apartment — Updated" \ -d "meta[price]=26500000"
The authenticated user needs permission to edit that post. A contributor should not be able to edit another author’s listing merely because the client knows its ID.
Read and write meta separately
Read one key:
curl "https://example.com/api/postsplus/get_post_meta/?post_id=123&key=price"
Read all meta:
curl "https://example.com/api/postsplus/get_post_meta/?post_id=123"
Set several keys:
curl -X POST "https://example.com/api/postsplus/set_post_meta/" \ -H "Authorization: Bearer eyJ..." \ -d "post_id=123" \ -d "meta[price]=26500000" \ -d "meta[currency]=PKR"
Delete a key:
curl -X POST "https://example.com/api/postsplus/delete_post_meta/" \ -H "Authorization: Bearer eyJ..." \ -d "post_id=123" \ -d "key=featured"
In v5.0.4, get_post_meta is public and can return all stored meta for a post. Review that carefully before production: WordPress post meta may include plugin-internal or sensitive values. Prefer exposing an allowlisted projection through a small server customization when the content model contains anything not intended for public clients.
Manage taxonomy terms
Assign existing term IDs or names to a post:
curl -X POST "https://example.com/api/postsplus/set_post_terms/" \ -H "Authorization: Bearer eyJ..." \ -d "post_id=123" \ -d "taxonomy=property_city" \ -d "terms[]=lahore" \ -d "append=0"
PostsPlus also offers protected create_term, update_term, and delete_term endpoints. These enforce taxonomy capabilities, so ordinary app users should not receive term-management roles unless taxonomy editing is a real product feature.
Add a featured image
create_post and update_post support an uploaded featured_image, a remote image_url, base64 image_data, or an existing featured_media ID. Prefer multipart upload or an existing media ID for larger images; base64 increases payload size.
Treat remote image URLs as untrusted input. Apply file-size, MIME-type, host, timeout, and image-processing limits at the server and infrastructure layers.
Model ACF-style fields in the app
Keep a typed client model instead of passing arbitrary meta everywhere:
type ListingFields = {
price: number;
currency: 'PKR' | 'USD';
bedrooms: number;
featured: boolean;
};
function toPostMeta(fields: ListingFields): Record<string, string> {
return {
price: String(fields.price),
currency: fields.currency,
bedrooms: String(fields.bedrooms),
featured: fields.featured ? 'yes' : 'no',
};
}
Mirror the validation on WordPress. Mobile validation improves UX; server validation protects the data.
Production checklist
- Register CPTs and taxonomies as public only when they should be discoverable.
- Map custom capabilities deliberately and assign least-privilege roles.
- Allowlist public and writable meta keys.
- Validate types, ranges, enum values, and relationships server-side.
- Paginate all collection screens and handle an empty or deleted term.
- Keep Pro
posts/*and User Pluspostsplus/*models separate. - Test authors editing their own content and attempts to edit someone else’s.
- Restrict upload sizes and remote-image behavior.
PostsPlus gives User Plus apps a broad content surface without competing with Pro’s controller. Used with capability mapping and meta allowlists, it is a practical bridge between WordPress’s flexible CPT model and a strongly typed mobile interface.
