Using the statpx REST API to Pull Your Analytics Data

The statpx dashboard gives you a clear visual summary of your site's traffic. But a dashboard is only one way to consume analytics data. For developers, data teams, and automation-minded site owners, a REST API opens up a different set of possibilities: feeding traffic numbers into your own tools, building custom reports, triggering workflows based on real data, and integrating analytics into places the standard UI was never designed to reach.

The statpx API is designed to be straightforward. Authenticate with a Bearer token, call an endpoint, receive JSON. This guide covers why you would use it, how authentication works, which endpoints are available, and what the responses look like.

Why Use an Analytics API

The most common reason to reach for an API rather than a dashboard is that you need the data to live somewhere other than a web browser. Some practical examples:

Custom Dashboards

Your team might already have a dashboard in Grafana, Notion, a custom internal tool, or a Retool app. Rather than maintaining a separate browser tab for analytics, you can pull statpx data into the same view your team already uses. A single unified dashboard reduces context-switching and makes cross-metric correlation easier — you can put traffic trends next to revenue numbers, support ticket volume, or deployment history.

Slack or Chat Bots

A bot that posts a daily traffic summary to your team's Slack channel, or alerts a channel when pageviews exceed a certain number, is easy to build with an API and a basic script. The bot runs on a schedule, calls the API, formats the result, and posts it. No manual checking, no report to pull — the data comes to the team automatically.

Spreadsheet Automation

Google Sheets and Excel both support pulling data from external APIs via scripts. A Google Apps Script that runs daily, calls the statpx API, and appends today's pageview count to a sheet gives you a growing historical record that you can chart, share, and analyze without ever opening the analytics dashboard.

CI/CD Pipeline Checks

After deploying a new version of your site, a post-deploy check can query the pageviews timeseries endpoint and compare traffic in the minutes after deploy to the same window the day before. A significant drop immediately after a deploy is a strong signal that something broke. Catching this in the pipeline, before the next morning's standup, is materially better than finding out hours later.

Third-Party Integrations

If you use tools that can call webhooks or external APIs — Zapier, Make, n8n — the statpx API is connectable. Pull weekly pageview counts into a CRM note, log daily session totals to a project management tool, or trigger a Slack notification when sessions drop below a threshold that your own alerting does not cover.

Authentication

All API requests require authentication. statpx uses API keys, which you generate from the API Keys page in your account settings. Each key has a name you choose, so you can create separate keys for different integrations and identify which one is in use if you need to revoke it.

Important: the full API key is shown only once, immediately after generation. Copy it and store it securely — a password manager is the right place. If you lose the key, you must generate a new one; there is no way to retrieve the original value.

Using Bearer Token Authentication

Pass your API key in the Authorization header of every request:

A full curl example looks like this:

Using the Query Parameter

Alternatively, you can pass the key as a query parameter. This is useful for quick testing in a browser or in tools that do not support custom headers easily:

The header method is preferred for production use. Query parameters can appear in server logs and browser history, which makes them less suitable for long-lived keys.

Available Endpoints

The statpx API uses a single base URL, https://statpx.com/api/index.php, and selects the endpoint with the endpoint query parameter. Six endpoints cover most needs.

GET ?endpoint=sites

Returns a list of all sites associated with your account. Use this to discover your site IDs, which are required parameters for the other endpoints.

Example request:

Example response:

GET ?endpoint=stats

Returns a metric for a site over the last 7, 30, or 90 days. Parameters:

• site_id — required, the numeric ID from endpoint=sites
• metric — one of pageviews (default), sessions, unique_visitors, bounce_rate, top_pages, top_referrers, countries
• range — 7, 30 (default), or 90 days

Example request:

Example response:

Time-series metrics (pageviews, sessions, unique_visitors) return a total plus a daily array. For unique_visitors, total counts each visitor once across the whole range, so it is usually lower than the sum of the daily values.

GET ?endpoint=pageviews

Returns a daily timeseries of pageviews and sessions for a site. Useful for charting traffic trends over time. Parameters:

• site_id — required
• range — 7 (default), 30, or 90 days

Example request:

Example response:

GET ?endpoint=events

Returns the custom events you track with _st('event', …). Each event includes its value and any custom props you attached. Requires owner or editor access to the site. Parameters:

• site_id — required
• name — filter by event name (optional)
• from / to — YYYY-MM-DD (default: last 30 days)
• group — name or value to get counts instead of raw rows (optional)
• limit (1–1000, default 500) and offset for paging

Example request:

Example response:

With group=value, you get one row per event name and value, with total occurrences and distinct sessions:

GET ?endpoint=realtime

A live snapshot of the last few minutes (bots excluded) — the same numbers as the Real-time page in your dashboard. Any team member with access to the site can call it. endpoint=real_time is accepted as an alias. Parameters:

• site_id — required
• metric — one of active_visitors, page_views, countries, active_pages, referrers. Omit it to get all five in one response.
• minutes — window size, 1–30 (default 5)

Example request:

Example response:

active_visitors counts distinct sessions in the window. Lists return the top 10 countries, top 20 pages and top 10 referrers. Poll every 15–30 seconds — that keeps you well under the 120 requests/minute limit.

GET ?endpoint=visitors

A visitor log with one row per pageview (bots excluded), newest first. Requires owner or editor access to the site. Parameters:

• site_id — required
• minutes — rolling window, 1–1440 (optional; takes precedence over from/to)
• from / to — YYYY-MM-DD (default: today)
• limit (1–1000, default 100) and offset for paging

Example request:

Example response (some fields omitted):

Each row also includes title, city, browser and os. IP addresses are masked to protect your visitors: the last part of an IPv4 address becomes x (203.0.113.x), and IPv6 addresses keep only the first three groups (2001:db8:abcd::). The full address is never returned by the API.

Managing API Keys

The statpx API Keys page (found in your account settings) is where you create, name, and revoke keys. A few practical guidelines:

Use One Key per Integration

Create a separate named key for each use case: one for your Slack bot, one for your Google Sheet, one for your CI pipeline. If you ever need to revoke access for one of them — because a project ends, a team member leaves, or a key is exposed — you can revoke just that key without disrupting the others.

Name Keys Descriptively

A key named "slack-weekly-digest" or "grafana-dashboard-prod" is easier to manage than "key1" or "api-key-june". The name is the only metadata you have after the key value is gone.

Rotate Keys Periodically

For long-lived integrations, rotating your API key every few months is a reasonable security habit. Generate the new key, update the integration, verify it works, then revoke the old key. The transition takes a few minutes and reduces the window of exposure if an old key was ever captured in a log somewhere.

A Simple Python Example

To illustrate how straightforward the API is to use, here is a minimal Python script that fetches the last 7 days of pageviews for a site and prints the total:

The same pattern works in Node.js, Ruby, PHP, Go, or any language with HTTP support. The API follows standard REST conventions — GET requests, query parameters, JSON responses, HTTP status codes for errors — so it integrates cleanly with any toolchain.

What to Build Next

The API is a starting point, not an endpoint. Once you have your data flowing into a custom integration, the useful things you can do with it compound. A Slack bot that started as a daily pageview summary can grow to include top pages, traffic source breakdowns, and week-over-week comparisons. A CI check that started as a basic drop detector can evolve into a full traffic health gate that blocks deploys when anomalies are detected.

The constraint is not the data — it is your imagination about what to do with it. Start with one simple integration, get it working, and let it grow from there.

The Bottom Line

An analytics REST API turns your traffic data from a dashboard-only view into a programmable resource — one you can feed into Slack bots, spreadsheets, CI pipelines, or any internal tool your team already uses. The practical step is to start small: generate a named API key, write a five-line script that pulls last week's pageviews, and get that working before building anything more ambitious. Once the data is flowing, useful integrations compound quickly. statpx exposes pageviews, sessions, unique visitors, and bounce rate through its API, with daily timeseries available for charting traffic trends in whatever tool you prefer.