Plugixa Testimonial REST API - Plugixa Testimonial

The integration surface for Plugixa Testimonial: testimonials you can list, create, edit, moderate, reorder and delete, categories and custom fields, e-mailed testimonial requests, saved views and shortcodes, import and export, translations, and the public routes the front end uses. Enough to sync testimonials from a CRM or a review platform, feed a headless site, or automate moderation.

The admin app uses these same routes, under the namespace plugixatestimonial/v1 (one word, no hyphen), so anything the admin can do with content, a script can do too. Every capability the interface checks is checked again at the endpoint.

Base URL

https://your-site.example/wp-json/plugixatestimonial/v1

On a site with plain permalinks, pass the route as a parameter instead:

https://your-site.example/?rest_route=/plugixatestimonial/v1/testimonials

Authentication

Plugixa Testimonial has no API keys of its own. It uses standard WordPress authentication:

Create an Application Password under Users -> Profile -> Application Passwords for the user the script should act as, then send it with the username:

curl -s "https://your-site.example/wp-json/plugixatestimonial/v1/testimonials" \
  -u "admin:$WP_APP_PASSWORD"

WordPress only accepts Application Passwords over HTTPS. A request that arrives signed out is refused with 403, not 401.

Capabilities

Each route checks one of four gates. The plugin gives its capabilities to the Administrator role on activation, and each gate except the last also accepts a WordPress capability, so an untouched site works without a role editor:

plugixa_testimonial_manage and plugixa_testimonial_settings exist but no route checks them.

Responses

Every successful response is wrapped the same way, with status 200, creates included:

{
  "success": true,
  "message": "Testimonial created successfully",
  "data": { "id": 42 }
}

message is a translated confirmation, empty on reads. A create answers only the new id in data.id: read the record back if you need it. File exports are the exception: they answer with the file itself.

Records are returned as they are stored. Numbers read from the database come back as strings ("id": "42", "rating": "5", "is_featured": "1"), null stays null, and datetimes are in the site’s time zone as 2026-11-12 09:30:00, not UTC. A request’s expires_at is the one datetime stored in UTC. Ids and counts the plugin computes itself (a new id, total) are real integers. Cast before you compare.

Lists and pagination

Paged list endpoints accept the same parameters and put the total in the body, not in headers (X-WP-Total is not sent).

search and status can also be sent at the top level. A page answers like this:

{
  "success": true,
  "message": "",
  "data": {
    "items": [ { "id": "42", "client_name": "Sarah Johnson" } ],
    "total": 37,
    "state": { "filter": { "status": "approved" }, "limit": 20, "offset": 0, "orderby": "created_at", "order": "DESC" }
  }
}

To walk every page, add limit to offset until offset reaches total, or send limit=-1. With WPML or Polylang active, rows also carry a translations list of { id, language_code }. There is no trash: deleted rows are gone. The public front-end lists page differently, with page and per_page: see List Approved Testimonials.

Endpoints

Everything except the PDF export is in the free build. The PRO route is registered only by the Pro build: on the free build it is not there at all and answers 404, rather than an upgrade message. Settings, the dashboard, the admin’s pickers and previews, font loading, demo data and the Pro Google, Facebook and review-source connections also live under this namespace, but they serve the admin screens and are not covered here.

Updates are not all alike

The single thing most likely to cost you an afternoon:

Each answers 200 even when nothing matched the id. Read the record, merge your change into it, and send the whole thing back.

Errors

Errors use the standard WordPress shape. The plugin’s own errors carry the code rest_error and an errors object, which names the fields for a validation failure and is empty otherwise:

{
  "code": "rest_error",
  "message": "Validation failed",
  "data": {
    "status": 400,
    "errors": { "testimonial_text": "Testimonial text must be at least 10 characters" }
  }
}

These can come back from any endpoint. Each endpoint page lists its own errors on top of them.

There is no rate limit on any route. The public submission route has none either, which is why reCAPTCHA is worth turning on for a public form: see Submission settings.

Caching

The public front-end lists are cached. Any write to this namespace (any request that is not a GET) clears that cache, so changes made through the API show at once. Changes written to the database by other means do not clear it.

No filter changes what these routes return. To change behaviour in PHP, see Hooks.

Troubleshooting

See also

• Move testimonials in bulk without code: Import and export.
• Ask customers for testimonials by e-mail: Testimonial requests.
• Change behaviour in PHP instead: Hooks.
• Everything else: Troubleshooting.