hosting

POST /v1/sites/bulk-vendor-operation

Run one hosting-platform operation across many of your sites at once.

모든 hosting 엔드포인트

인증

Bearer 토큰으로 API 키를 전송하세요. 키는 반드시 sites.view 권한을 가지고 있어야 하며, 권한이 없는 키는 404가 아닌 403으로 거부됩니다.

이 엔드포인트는 조직 ID를 받지 않습니다. 사용자의 키가 이미 속한 조직을 식별하며, 응답은 해당 조직으로 한정됩니다.

무료 체험하기

대괄호 안에 있는 모든 내용을 사용자 지정 값으로 바꾸고, 키 플레이스홀더는 대시보드의 키로 바꾸세요.

curl -X POST https://api.zinndigital.com/v1/sites/bulk-vendor-operation \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "operation": <string<block_ip, cache_purge, malware_scan, sitemap>>, "site_ids": <Uuid[]> }'

로그인하셨나요? 대시보드의 API 콘솔이 실제 조직 ID와 본인의 키를 자동으로 채우고 라이브 API를 대상으로 요청을 실행하므로 실제 응답을 확인할 수 있습니다. API 콘솔에서 이 엔드포인트를 여세요

상세 정보

Purge caches, fetch malware-scan results, regenerate sitemaps or set IP blocks for a whole selection of sites in **one call to the underlying hosting platform**, instead of one call per site. ⛔ **This is a rate-limit control, not a convenience.** The upstream platform limits by source IP — the one thing an API key cannot smooth — so 400 sites purged one at a time is 400 requests through a shared outbound pool that every other integration also uses. Here it is 8. `vendor_calls` in the response is that number, returned so a client can see the guarantee holding; if it ever equals the number of sites, the batching has regressed. ⛔⛔ **The response is per site and is never a bare success.** The platform answers per package and a batch can come back partially acknowledged, so results arrive in three disjoint lists that add up to `requested`: `succeeded` (the vendor confirmed it), `failed` (the vendor was asked and did not confirm, or the batch errored) and `skipped` (we could not ask at all — the site is not on a vendor hosting package, or it has no recorded package id). A client that renders only `succeeded` will tell a customer about 42 sites when they selected 50. ⚠️ Only site ids are accepted, never vendor package ids: a package id is an integer anyone could type and the upstream platform would act on it regardless of which customer it belongs to. Ids are resolved inside the caller's own organisation. ⛔ Two of the platform's bulk operations are deliberately **not** offered. Country-blocking appends a line to the site's `.htaccess` on every call and never removes it, so it is not safe behind a retry — set it per site instead. Bulk deletion would bypass the quarantine, audit and undo that the normal delete flow provides. Asking for either answers `422` naming the reason and the alternative. Requires `sites.view` and `sites.restart`.

요청 본문

이름유형필수설명
operationstring<block_ip, cache_purge, malware_scan, sitemap>Which platform operation to run. ⛔ A closed set, not a passthrough — a client cannot name an upstream path. `block_country` and `delete` are deliberately absent and answer `422`…
site_idsUuid[]The sites to act on, in the caller's own organisation. ⚠️ Site ids only — never vendor package ids.

응답

이름유형필수설명
operationstringThe operation that was run.
requestedintegerHow many sites were asked for. ⛔ `succeeded + failed + skipped` always equals this — the three lists are disjoint and complete, so a client can never quietly lose a site.
succeededBulkVendorSiteResult[]
failedBulkVendorSiteResult[]Asked for, and the platform did not confirm it.
skippedBulkVendorSiteResult[]Could not be asked about at all — not on a vendor hosting package, or no recorded package id. Neither a success nor a failure, and shown to the customer as its own outcome.
vendor_callsintegerHow many upstream calls this took. The whole point of the endpoint is that this is much smaller than `requested`.

이 엔드포인트가 반환할 수 있는 오류

401 · 403 · 422 · 429