REST API reference

Complete reference for all WP-PFManagement REST API endpoints. Base URL: /wp-json/pfm/v1/

Authentication

Most endpoints require WordPress authentication via X-WP-Nonce header. Entity CRUD endpoints use a permission resolver that evaluates the current user's roles against the entity's role columns.

Entity & schema management

Form layouts

Auto-numbering

Navigation

Templates

Records

filter is STRICT EQL: a query that does not parse comes back as 400 pfm_eql_unparseable, never as a successful list with no rows — an integration must be able to tell "your query is wrong" from "nothing matches". Free text belongs in search, which looks through the table's text fields and, when both are sent, narrows inside the filter instead of widening past it.

?include=<field>[,<field>…] deep-loads forward RELATION fields: the target records are returned in an included block keyed by field then by sys_id, so the FK carried on each row joins to its record without an N+1 fetch. Every include honours the same read gates as a direct read (entity ACL, api_exposable, row-visibility, field projection); an unreadable target is silently omitted.

Rate limits

Two ceilings, per caller (per user when signed in, per IP otherwise), counted in one-minute windows. Both answer 429 with a Retry-After header rather than failing silently, and both are bypassed for WP-CLI and cron.

The write ceiling is two changes a second sustained, which no person and no screen of ours reaches — the widest burst the product itself produces is a planning save, one record per moved node. It exists so a leaked cookie or a runaway script cannot create rows until the disk fills. If your instance genuinely needs more (a bulk loader of your own, or a limiter already in front of the site), raise or remove it:

add_filter( 'pfm_write_rate_limit_per_minute', fn() => 600 ); // 0 disables it

Anonymous record creation carries its own separate hardening (honeypot + per-entity limit) on top of this.

Response headers, and which ones we control

Every response on this namespace carries X-Request-ID (quote it in a support request), Server-Timing: pfm;dur=<ms> (how long our dispatch took — elapsed time only, no internals), X-Frame-Options, X-Content-Type-Options and Referrer-Policy, plus Vary: Cookie, Origin on user-scoped routes.

X-Powered-By is removed: PHP announces its exact version there by default, and that is precisely what someone probing for a known vulnerability wants.

The Server header is NOT ours. Apache (or nginx) adds it after PHP has finished, so no plugin can remove or change it — verified rather than assumed. If your server announces its version and you would rather it did not, that is a one-line change in YOUR server configuration:

ServerTokens Prod

server_tokens off;

API keys (machine callers)

Integrations authenticate with Authorization: Bearer pfmk_…, resolved to a least-privilege service user. A key carries a { entities, verbs } scope that INTERSECTS the service user's role grants (it never widens them), and it can only reach entities an operator has flagged api_exposable. Keys are schema-manager-gated; the plaintext token is shown once at mint.

Journal

Events

Actions

Permissions

Business Rules

UI Policies

Row Visibility

User Preferences

Public / Front-end

Agent & system

Error format

{
  "status": "fail",
  "error": "entity_not_found",
  "detail": "No entity exists with slug 'tickets'"
}