hosting

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

Mint a one-click WordPress admin login token.

المصادقة

أرسل مفتاح واجهة برمجة التطبيقات (API key) كرمز حامل (bearer token). يجب أن يحمل المفتاح إذن sites.wp_login؛ والمفتاح الذي لا يملكه يُرفض بالرمز 403 وليس 404.

لا يقبل هذا الطرف أي معرف للمؤسسة. يحدد مفتاحك بالفعل المؤسسة التي ينتمي إليها، وتكون الاستجابة محصورة في نطاقها.

جربه الآن

استبدل أي شيء بين أقواس زاوية بقيمك الخاصة، والعنصر النائب للمفتاح بمفتاح من لوحة تحكمك.

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

هل سجلت الدخول؟ تقوم وحدة تحكم واجهة برمجة التطبيقات في لوحة التحكم الخاصة بك بربط معرف مؤسستك الحقيقي ومفتاحك الخاص، وتنفذ الطلب مقابل واجهة برمجة التطبيقات المباشرة لتتمكن من رؤية الاستجابة الفعلية. افتح هذه النهاية الطرفية في وحدة تحكم 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 error body's `reason` carries which of those failed, so a client can say the true thing instead of "something went wrong".

المعلمات

الاسم	النوع	مطلوب	ما هو هذا
`siteId (path)`	`Uuid`	نعم	Site ID (UUIDv7).

جسم الطلب

الاسم	النوع	مطلوب	ما هو هذا
`wp_username`	`string`	لا	The WordPress user to sign in as. Omit or leave blank for the site's primary administrator (the plugin resolves it).

الاستجابة

الاسم	النوع	مطلوب	ما هو هذا
`url`	`string`	نعم	The site URL carrying the token — send the customer's browser here to complete one-click login. The token is single-use and short-lived.
`token`	`string`	نعم	The signed SSO token (also embedded in `url`).
`wp_username`	`string`	نعم	The target WordPress user ("" = the site's primary administrator).
`expires_at`	`string`	نعم	When the token expires (UTC).

الأخطاء التي يمكن أن تُرجعها نقطة النهاية هذه

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

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