Headless & JWT

Build a decoupled front end, mobile app, or server-to-server check against Tiger Membership using a signed JWT and the headless REST API. Exchange credentials for a short-lived token, then ask the canonical /access endpoint whether an identity may see a given object — the same resolver that gates normal WordPress page loads.

Where: REST endpoints under the plugin’s namespace — POST /auth/token and GET /access.  Tier: Pro (JWT issuance ships only in the Pro build).

Getting a token

POST a WordPress username and password to the /auth/token endpoint to receive a JWT. Tokens are HS256, short-lived (15 minutes), and signed with a key derived from your license — so deactivating or rotating the license invalidates every outstanding token. The response returns { token, expiresAt, userId }.

Because the endpoint is unauthenticated and takes a password, issuance is rate-limited per client IP: after about 10 failed attempts in a 15-minute window it returns 429 Too Many Attempts with a Retry-After header. A successful login clears the counter.

Calling the API

Send the token as a Authorization: Bearer <token> header on subsequent requests. The headless resolver reads the Bearer token first, then falls back to the normal WordPress session, then to guest.

The /access gate

GET /access?object=<id-or-url> answers “can this identity see this object?”. When allowed it returns allowed: true. When blocked it returns allowed: false along with the required plan ids, ready-to-render teaser/blur HTML (when the rule’s behavior is teaser or blur), and an upgrade URL — everything a headless UI needs to show a paywall without duplicating your rules.

Example

1. POST /auth/token with { "username": "...", "password": "..." } → receive token.
2. Call GET /access?object=42 with Authorization: Bearer <token>.
3. Render the content if allowed, otherwise show the returned teaser and upgrade URL.

Troubleshooting

The token endpoint returns 402.

Headless JWT auth is a Pro feature. Activate a Pro license; without it, /auth/token refuses to issue tokens (the /access gate itself still works using the WP session).

My requests are suddenly rejected with 401.

Tokens expire after 15 minutes, and the signing key is tied to your license — a token also becomes invalid if the license is deactivated or rotated. Request a fresh token.

I’m getting 429 from /auth/token.

Too many failed logins from your IP. Wait for the window in the Retry-After header, and verify the credentials — a correct login clears the throttle.