hosting
GET /v1/sites/{siteId}/vitals/history
Get a site's speed history and change timeline.
ప్రమాణీకరణ
ఒక API కీని బేరర్ టోకెన్గా పంపండి. ఈ ఎండ్పాయింట్ స్పెసిఫికేషన్లో నిర్దిష్ట అనుమతిని పేర్కొనలేదు, కాబట్టి ఊహించడం కంటే మీ కీకి అవసరమైన కనిష్ట అనుమతిని ఇవ్వండి మరియు ప్రతిస్పందనను తనిఖీ చేయండి.
ఈ ఎండ్పాయింట్ ఎలాంటి సంస్థ ఐడీని తీసుకోదు. మీ కీ ఇప్పటికే అది ఏ సంస్థకు చెందుతుందో గుర్తిస్తుంది మరియు ప్రతిస్పందన దానికే పరిమితం చేయబడుతుంది.
ప్రయత్నించండి
కోణీయ బ్రాకెట్లలో ఉన్న దేన్నైనా మీ స్వంత విలువలతో భర్తీ చేయండి, మరియు కీ ప్లేస్హోల్డర్ను మీ డాష్బోర్డ్ నుండి తీసుకున్న కీతో భర్తీ చేయండి.
curl -X GET https://api.zinndigital.com/v1/sites/{siteId}/vitals/history \
-H "Authorization: Bearer zdk_live_…"సైన్ ఇన్ చేశారా? మీ డ్యాష్బోర్డ్లోని API కాన్సోల్ మీ అసలైన సంస్థ ID మరియు మీ స్వంత కీని నింపుతుంది, అలాగే మీరు అసలైన ప్రతిస్పందనను చూడటానికి లైవ్ API ద్వారా ఆభ్యర్థనను రన్ చేస్తుంది. ఈ ఎండ్పాయింట్ను API కన్సోల్లో తెరిచండి
వివరాలు
How the site's speed has moved over time, **and what changed on the site**, on one axis — so a customer can see that activating a plugin cost them 0.4 s rather than having to remember it. **This is the consumer that was missing.** Vitals rows have been kept since #626 with a comment saying they exist "so the Performance tab can show a trend"; nothing ever read them, there was no time-series endpoint, and there was no charting library in the repo. The trend was being stored correctly, for weeks, for nobody. **Two producers, one axis.** `points` are Lighthouse measurements taken off the request path by a scheduled sweep. `events` are what the site reported about itself over a signed webhook (plugin activated, core updated, theme switched, PHP version changed), merged with its successful deploys. Events carry the time they happened **on the site**, so a webhook delivered late still lands beside the score it explains. **`score_delta` is computed here.** Two clients subtracting two nullable columns is two chances to render `-87` for "we did not measure the earlier one". ⚠️ **Cadence.** The sweep measures a fixed number of sites per hour, so on a large estate a site's points can be days apart. A site that reports a change is moved to the front of the next sweep, which is why the timeline — not the sweep — is the primary signal for attributing a regression (docs/85 §4.2). RLS-scoped to a site the caller can view (`sites.view`); an out-of-scope or unknown id is a `404` alike, exactly like `getSite`.
పారామీటర్లు
| పేరు | రకం | కావలసినది | ఇది ఏమిటి |
|---|---|---|---|
siteId (path) | Uuid | అవును | Site ID (UUIDv7). |
days (query) | integer | కాదు | How far back to look. Clamped rather than rejected — this is a cheap read of the caller's own data, so a `422` on `days=0` would be a worse experience than a sensible window, an… |
స్పందన
| పేరు | రకం | కావలసినది | ఇది ఏమిటి |
|---|---|---|---|
points | SiteVitalsHistoryPoint[] | అవును | Oldest → newest, so a chart renders it without reversing. Capped; when a site has more measurements than the cap, the **most recent** are returned — a chart that stopped before… |
events | SiteEvent[] | అవును | Oldest → newest, on the same axis as `points`. |
stack_type | string | అవును | The site's configured stack — `static`, `php`, `wordpress`, `woocommerce`, `node`, `one_click`. Decides which advice and which events apply: a static site must never be given Wo… |
stack_packs | string[] | అవును | What the newest lab run detected. Resolves `one_click`, which is a container for "whatever the customer installed" and therefore knows nothing about itself. |
opportunities | SiteVitalsOpportunity[] | అవును | The newest lab run's opportunities. On a customer surface these are the same rows `getSiteVitals` returns; on the staff surface they additionally include `owner: platform` audit… |
recommendation | SpeedUpRecommendation | అవును | Which optimisation tier to lead with for this site, and the evidence for it (docs/85 §7). Before this, the speed-up offer fired on a traffic-light band alone while the platform… |
ఈ ఎండ్పాయింట్ తిరిగి ఇవ్వగల లోపాలు
401 · 403 · 404 · 429