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

Uthibitishaji

Tuma ufunguo wa API kama tokeni ya kubeba. Ufunguo lazima uwe na ruhusa ya sites.wp_login; ufunguo usio nayo unakataliwa kwa 403, si 404.

Endpoint hii haichukui kitambulisho cha shirika. Ufunguo wako tayari unalitambua shirika linalohusika, na jibu limewekewa kikomo kwa shirika hilo pekee.

Jaribu

Badilisha chochote kilicho ndani ya mabano ya pembe na maadili yako mwenyewe, na kishikiliaji cha ufunguo na ufunguo kutoka kwa dashibodi yako.

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

Umeingia kwenye akaunti? Dashibodi yako ya kiweko cha API inajaza kitambulisho chako halisi cha shirika na ufunguo wako mwenyewe, na kuendesha ombi dhidi ya API ya moja kwa moja ili uweze kuona jibu halisi. Fungua sehemu hii ya mwisho (endpoint) kwenye konsole ya API

Maelezo

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".

Vigezo

Mwili wa ombi

Majibu

Hitilafu ambazo mwisho huu unaweza kurudisha

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