hosting

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

Mint a one-click WordPress admin login token.

ದೃಢೀಕರಣ

ಬೇರರ್ ಟೋಕನ್ ಆಗಿ API ಕೀಯನ್ನು ಕಳುಹಿಸಿ. ಕೀಯು sites.wp_login ಅನುಮತಿಯನ್ನು ಹೊಂದಿರಬೇಕು; ಅದನ್ನು ಹೊಂದಿರದ ಕೀಯನ್ನು 404 ಬದಲಿಗೆ 403 ನೊಂದಿಗೆ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.

ಈ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಯಾವುದೇ ಸಂಸ್ಥೆಯ ಐಡಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ನಿಮ್ಮ ಕೀ ಯು ಈಗಾಗಲೇ ಅದು ಸೇರಿರುವ ಸಂಸ್ಥೆಯನ್ನು ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅದಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಲಾಗಿದೆ.

ಪ್ರಯತ್ನಿಸಿ

ಕೋನೀಯ ಬ್ರಾಕೆಟ್‌ಗಳಲ್ಲಿರುವ ಯಾವುದೇ ಅಂಶವನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಮತ್ತು ಕೀ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಅನ್ನು ನಿಮ್ಮ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿರುವ ಕೀಯೊಂದಿಗೆ ಬದಲಾಯಿಸಿ.

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