REST API
Setyenv exposes REST endpoints at two layers:
- Portal endpoints under
/wp-json/pfw-portal/v1/...onsetyenv.com. Handle licensing, downloads, telemetry, customer dashboard operations. Documented in this section. - Plugin endpoints under
/wp-json/pfw-workflow/v1/...,/wp-json/pfw-agent/v1/...,/wp-json/pfw-management/v1/...on YOUR WordPress install (each plugin exposes its own surface). Documented under each product's REST section.
Authentication
Public endpoints (the prebuy / cold-buy flow, telemetry receivers) do not require authentication and use HMAC-signed payloads where tamper-resistance matters.
Customer-facing endpoints (the dashboard) use standard WordPress cookie auth + a X-WP-Nonce header generated by wp_create_nonce('wp_rest').
Plugin-to-portal endpoints (license activate / verify) use the per-site token issued at activation. Send it as Authorization: Bearer <token>.
Versioning
All routes are namespaced under v1. Breaking changes get a new namespace (v2); we keep v1 running until the legal end-of-life window passes. Non-breaking additions ship in-place under v1.
Error format
Every endpoint returns a consistent envelope:
{
"status": "ok",
"data": { ... }
}
or on error:
{
"status": "fail",
"error": "license_not_found",
"detail": "Optional human-readable explanation"
}
The HTTP status code mirrors the failure class: 400 for malformed requests, 401 for missing auth, 403 for forbidden, 404 for not-found, 422 for valid request but unmet preconditions, 500 for portal bugs, 502 for upstream provider (Stripe, etc.) failures.