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

Аутентификација

Пошаљите API кључ као bearer токен. Кључ мора имати дозволу sites.wp_login; кључ без ње се одбија уз 403, а не 404.

Ова крајња тачка не прихвата id организације. Ваш кључ већ идентификује организацију којој припада, а одговор је ограничен на њу.

Испробајте

Замените све што је у угластим заградама сопственим вредностима, а чувар места кључа кључем са своје контролне табле.

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

Пријављени сте? API конзола на вашој контролној табли попуњава ваш прави id организације и ваш сопствени кључ, и покреће захтев према живом API-ју како бисте могли да видите стварни одговор. Отворите ову крајњу тачку у API конзоли

Детаљи

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 site's domain actually serves THIS site: while a partner move into it is not yet live (the domain still opens the original copy) the answer is 409 with details[].code move_in_progress, and while an import into it is unfinished, import_in_progress — never a login URL that would open someone else's server. The error body's reason carries which of those failed, so a client can say the true thing instead of "something went wrong".

Параметри

Тело захтева

Одговор

Грешке које ова крајња тачка може вратити

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