hosting
POST /v1/site-events/ingest
Receive a site's report about its own changes (signed webhook).
ప్రమాణీకరణ
ఈ ఎండ్పాయింట్ పబ్లిక్. దీనికి ఎలాంటి ఆధారాలు మరియు సంస్థ అవసరం లేదు — మన స్వంత మార్కెటింగ్ సైట్ మరియు AI సమాధాన ఇంజిన్లు చదివేది ఇదే.
ఈ ఎండ్పాయింట్ ఎలాంటి సంస్థ ఐడీని తీసుకోదు. మీ కీ ఇప్పటికే అది ఏ సంస్థకు చెందుతుందో గుర్తిస్తుంది మరియు ప్రతిస్పందన దానికే పరిమితం చేయబడుతుంది.
ప్రయత్నించండి
కోణీయ బ్రాకెట్లలో ఉన్న దేన్నైనా మీ స్వంత విలువలతో భర్తీ చేయండి, మరియు కీ ప్లేస్హోల్డర్ను మీ డాష్బోర్డ్ నుండి తీసుకున్న కీతో భర్తీ చేయండి.
curl -X POST https://api.zinndigital.com/v1/site-events/ingest \
-H "Content-Type: application/json" \
-d '{ "site": <string> }'సైన్ ఇన్ చేశారా? మీ డ్యాష్బోర్డ్లోని API కాన్సోల్ మీ అసలైన సంస్థ ID మరియు మీ స్వంత కీని నింపుతుంది, అలాగే మీరు అసలైన ప్రతిస్పందనను చూడటానికి లైవ్ API ద్వారా ఆభ్యర్థనను రన్ చేస్తుంది. ఈ ఎండ్పాయింట్ను API కన్సోల్లో తెరిచండి
వివరాలు
What a site's Zinn® plugin POSTs when something changed on it — a plugin activated or deactivated, core or a theme updated, a theme switched — plus the PHP version it is running. **Machine-to-machine; there is no principal.** WordPress is talking, not a person, so there is no session, no API key and no organisation header. Authentication is an **HMAC-SHA256** over `"<timestamp>\n<body>"` in `X-Zinn-Cache-Signature` (`sha256=<hex>`), with `X-Zinn-Cache-Timestamp` carrying the unix seconds — the same scheme the plugin already uses for its cache-purge mirror. **The secret is derived, never stored.** The engine resolves `site` to a hosted site by primary domain, derives that site's webhook secret from the platform master key, and compares in constant time. The organisation comes from the **resolved site**: a valid signature proves the sender holds that site's secret and proves nothing whatsoever about any other tenant. **Every refusal is uninformative on purpose.** An unknown hostname is a bare `404` and a bad signature a bare `401`, because a chattier answer would tell anyone who can guess a hostname which domains this platform hosts. **Idempotent.** WordPress fires some of these hooks more than once per change and the POST is fire-and-forget, so a duplicate delivery is accepted with `stored: 0` rather than refused — replay safety lives in the database.
పారామీటర్లు
| పేరు | రకం | కావలసినది | ఇది ఏమిటి |
|---|---|---|---|
X-Zinn-Cache-Timestamp (header) | string | అవును | Unix seconds. Signed as part of the material, which is what makes the replay window meaningful — a signature over the body alone could be replayed for ever with a fresh header. |
X-Zinn-Cache-Signature (header) | string | అవును | `sha256=<hex>`. |
అభ్యర్థన బాడీ
| పేరు | రకం | కావలసినది | ఇది ఏమిటి |
|---|---|---|---|
site | string | అవును | The site's own `home_url()`. **An untrusted claim** — it selects which site's derived secret the signature is checked against, and nothing more. The organisation is taken from t… |
php_version | string | కాదు | The PHP version the site is running. The engine raises a `php_version_changed` event when it differs from the last one reported — a change is detectable by **comparison** rather… |
events | object[] | కాదు | A batch. WordPress bulk-updating 40 plugins fires one `upgrader_process_complete` describing all of them, so a batch is the normal case, not the edge case. `deploy` is rejected… |
స్పందన
| పేరు | రకం | కావలసినది | ఇది ఏమిటి |
|---|---|---|---|
accepted | boolean | అవును | — |
stored | integer | అవును | How many rows were **new**. A duplicate delivery is accepted with `0` rather than refused: WordPress fires some of these hooks more than once per change and the POST is fire-and… |
ఈ ఎండ్పాయింట్ తిరిగి ఇవ్వగల లోపాలు
401 · 404 · 422 · 503