POST /v1/sites/{siteId}/wp-login

Authentifizierung

Senden Sie einen API-Schlüssel als Bearer-Token. Der Schlüssel muss über die Berechtigung sites.wp_login verfügen; ein Schlüssel ohne diese wird mit 403 statt 404 abgelehnt.

Dieser Endpunkt erfordert keine Organisations-ID. Ihr Schlüssel identifiziert bereits die zugehörige Organisation, und die Antwort ist entsprechend eingeschränkt.

Ausprobieren

Ersetzen Sie alles in spitzen Klammern durch Ihre eigenen Werte und den Platzhalter für den Schlüssel durch einen Schlüssel aus Ihrem Dashboard.

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/wp-login \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{  }'

Angemeldet? Die API-Konsole in Ihrem Dashboard trägt automatisch Ihre echte Organisations-ID sowie Ihren eigenen Schlüssel ein und führt die Anfrage gegen die Live-API aus, sodass Sie die tatsächliche Antwort sehen können. Öffnen Sie diesen Endpunkt in der API-Konsole

Details

Returns a short-lived, signed SSO token (and the URL that carries it) for one-click sign-in to the site's `wp-admin` (V1 parity). The customer's browser is sent to the URL; the Zinn® plugin on the site verifies the token, enforces single-use, and establishes the wp-admin session. The token is bound to this site, expires in ~2 minutes, and its issuance is audit-logged with the real actor. Requires `sites.wp_login`. Only WordPress/WooCommerce sites that are **serving** are eligible (422 / 409 otherwise); if one-click login is not configured on the platform the endpoint returns 503 and mints nothing. ⛔⛔ **A `201` from this endpoint is a claim about the SITE, not merely about the signature, and it did not used to be.** Minting is local, cheap and always succeeds; every reason a grant cannot work lives on the box. Before the preflight below existed this endpoint answered `201` with a correctly-signed URL for a site whose WordPress had no SSO key, no plugin to serve the route, and — measured on 2026-08-15 — was returning **HTTP 500 to every request**. Three such grants were issued and audit-logged in one day, each of which opened an error page. So before signing anything the endpoint now checks, and repairs what it can: * the hosting platform can receive an SSO key at all — this platform exposes no shell and no wp-cli, so its sites can never honour one and are refused `422` (`PLATFORM_CANNOT_SSO`) rather than handed a token; * the plugin that serves the route is installed and active — **installed automatically if it is not**, because a precondition the platform can satisfy itself is not one the customer should read about; * the site's `ZINN_SSO_KEY` is present **on the box**, asked of the file rather than of our own record of having written it — the two disagreed; * and the site actually answers HTTP without a server error, probed from the box against the origin so a CDN cache cannot report health the site no longer has. A site that fails this is `409` (`SITE_NOT_REACHABLE`). The error body's `reason` carries which of those failed, so a client can say the true thing instead of "something went wrong".

Parameter

Anfragekörper

Antwort

Fehler, die dieser Endpunkt zurückgeben kann

401 · 403 · 404 · 409 · 422 · 429 · 503