Setyenv · Docs
  • English
  • Español
  • 中文
  • 日本語
  • العربية
  • Deutsch
  • Français
  • हिन्दी
  • Bahasa Indonesia
  • Italiano
  • Nederlands
  • Português
  • Русский
  • Türkçe

REST API

Setyenv exposes REST endpoints at two layers:

  • Portal endpoints under /wp-json/pfw-portal/v1/... on setyenv.com. Handle licensing, presence, downloads and 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 (licence activate / verify / deactivate and the presence report) carry no session: the licence key travels in the URL and the site identifies itself by its fingerprint. They are rate-limited per IP.

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.