hosting

GET /v1/sites/{siteId}/vitals/history

Get a site's speed history and change timeline.

Όλα τα τελικά σημεία hosting

Όλα τα έγγραφα προγραμματιστών

Πισtoποίηση

Στείλτε ένα κλειδί API ως διακριτικό φορέα (bearer token). Αυτό το τελικό σημείο δεν ορίζει μια συγκεκριμένη άδεια στην προδιαγραφή, οπότε δώστε στο κλειδί σας τα ελάχιστα δυνατά δικαιώματα και ελέγξτε την απόκριση αντί να κάνετε υποθέσεις.

Αυτό το τελικό σημείο δεν δέχεται αναγνωριστικό οργανισμού. Το κλειδί σας προσδιορίζει ήδη τον οργανισμό στον οποίο ανήκει, και η απάντηση περιορίζεται σε αυτόν.

Δοκιμάστε το

Ατικatastήstε ό,τι βρίskεtai μέσα σe γώniaδeς μe τis δikές sas timές, kai to placeholder klεidioύ μe éna klεidi apó ton pinaka ελέgchou sas.

curl -X GET https://api.zinndigital.com/v1/sites/{siteId}/vitals/history \
  -H "Authorization: Bearer zdk_live_…"

Συνδεθήκατε; Η κονσόλα API στον πίνακα ελέγχου σας συμπληρώνει το πραγματικό αναγνωριστικό του οργανισμού σας και το δικό σας κλειδί, και εκτελεί το αίτημα στο ζωντανό 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.

Παράμετροι

ΌνομαΤύpοςΥποχρεωτικόΤι είναι
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, and…

Απάντηση

ΌνομαΤύpοςΥποχρεωτικόΤι είναι
pointsSiteVitalsHistoryPoint[]Ναι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…
eventsSiteEvent[]ΝαιOldest → newest, on the same axis as points.
stack_typestringΝαι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…
stack_packsstring[]ΝαιWhat the newest lab run detected. Resolves one_click, which is a container for "whatever the customer installed" and therefore knows nothing about itself.
opportunitiesSiteVitalsOpportunity[]Ναι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 audits,…
recommendationSpeedUpRecommendationΝαι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