Top paths
The most-viewed paths over a window, highest first.
https://webbuddy.radioworkflow.com/api/v1/analytics/top-pathsanalytics:readPaths ranked by total views across the window, highest first. Paths are the raw request paths as recorded, including any query-free trailing segments — they are not normalised or grouped.
Like the daily series, this returns an empty array rather than an error before a site's first visitor, so an empty result 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. |
| limit | integer1–100 | Optional | 10 | How many paths to return. Values outside the range are clamped rather than rejected. |
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/top-paths?days=30&limit=10' \ -H "Authorization: Bearer wb_live_your_key_here"
Try it
This form calls /api/v1/analytics/top-paths 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
1–100 · default 10 · outside the range is clamped, not refused
GET /api/v1/analytics/top-paths?days=30&limit=10 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 |
|---|---|---|
| path | string | The request path, beginning with /. |
| views | integer | Total views for that path across the window. |
Up to limit elements — fewer when the site has fewer distinct paths, and none at all when there is no traffic in the window.
[
{ "path": "/", "views": 5120 },
{ "path": "/sports/tigers-win-the-final", "views": 842 },
{ "path": "/news/city-council-recap", "views": 511 },
{ "path": "/weather", "views": 402 },
{ "path": "/obituaries", "views": 288 }
]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.