Daily page views
Page-view counts per day over a window, oldest first and zero-filled.
https://webbuddy.radioworkflow.com/api/v1/analytics/dailyanalytics:readOne row per day in the window, ending today, oldest first. The series is ZERO-FILLED: every day in the window is present even when nothing was served, so a chart can plot the array directly without reconstructing a date spine.
Days are bucketed in UTC, which is worth knowing if your audience is not — a view at 7pm Pacific lands on the following UTC day.
Before a site's first visitor, or where page-view collection is not wired up yet, this returns an all-zero window rather than an error or an empty array. An all-zero response therefore does not distinguish 'no traffic' from 'not collecting'.
Authentication
| Header | Required | Value |
|---|---|---|
| Authorization | Required | Bearer wb_live_your_key_here The site API key as a bearer token: Bearer wb_live_…. It is the only credential — there are no cookies, no session and no CSRF token in this API. |
The key must also carry the analytics:readscope. Scopes are ticked when a key is created on the site's API tab and cannot be added afterwards — a key without this one answers insufficient_scope to this endpoint however many times it is retried, so the fix is a new key. What each scope unlocks.
Parameters
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| days | integer1–90 | Optional | 30 | How many days back to include, ending today (UTC). Values outside the range are clamped rather than rejected, and a non-numeric value falls back to the default. |
Out-of-range values are clamped, not rejected. A request outside the published range still answers 200 — with the nearest allowed value applied, and a value that is not a number falling back to the default. Nothing in the response says this happened, so validate before you send if the exact window matters.
Request
curl 'https://webbuddy.radioworkflow.com/api/v1/analytics/daily?days=30' \ -H "Authorization: Bearer wb_live_your_key_here"
Try it
This form calls /api/v1/analytics/daily from your browser, straight to the API, on this same origin. The key you paste below is put into an Authorization header on that one request — it is not sent to the documentation, not written to storage on this device, and not kept once you close the tab.
It is a real request against a real key: it counts against the same limit as any other call — 120 per minute per key — and it appears in your site's API log like anything else you send.
A live key for the site, carrying the analytics:read scope.
1–90 · default 30 · outside the range is clamped, not refused
GET /api/v1/analytics/daily?days=30 Authorization: Bearer wb_live_your_key_here
The placeholder above is what the docs print. Your key is never shown back to you here, in the preview or in the response.
Response
application/jsonA JSON array — the fields below describe one element.| Field | Type | Description |
|---|---|---|
| day | string | The UTC date, as YYYY-MM-DD. |
| views | integer | Page views recorded on that day. Zero-filled. |
Exactly days elements, always — oldest first, no gaps.
[
{ "day": "2026-07-12", "views": 0 },
{ "day": "2026-07-13", "views": 143 },
{ "day": "2026-07-14", "views": 168 },
{ "day": "2026-07-15", "views": 201 },
{ "day": "2026-07-16", "views": 190 },
{ "day": "2026-07-17", "views": 233 },
{ "day": "2026-07-18", "views": 88 }
]Every response also carries the headers listed under what every response carries.
Errors
| HTTP | code | Retry? | What to do |
|---|---|---|---|
| 401 | unauthorized | Do not | Check the header is exactly Authorization: Bearer wb_live_…. If it is, the key was probably revoked — mint a new one on the site's API tab. Do not retry: nothing about this request will succeed on a second attempt. |
| 403 | insufficient_scope | Do not | Mint a new key on the site's API tab with the required scope ticked, then revoke the old one. Do not retry: the same key answers 403 forever. The message names the scope that was missing. |
| 429 | rate_limited | Retry | Back off and retry — the window is at most 60 seconds long, so an exponential backoff starting around a second will clear it. If you hit this steadily, cache the responses you poll rather than raising your request rate. If the message mentions failed authentications, fix the key first: retrying the same bad token is what filled that bucket. |
| 500 | internal_error | Retry | Retry once after a short delay. If it persists for a given endpoint, it is a bug on our side rather than something your request can fix; report it with the endpoint and the time. |
What each code means, and the envelope they arrive in, are on the errors page.