Build custom reports

When the App dashboard doesn't have the metric your team cares about, the analytics API hands back the same pre-aggregated rollups the dashboard is built on. Wire them into your existing BI tool, ops alerting, or weekly report.

What the analytics API exposes

• Yearly summaries — top-line totals for long-range trends. The right shape for executive year-over-year comparisons.
• Daily summaries — daily rollups of cache hits, misses, and warehouse-bound volume. The right shape for week/month dashboards and threshold-based alerting.
• Per-user summaries — usage and outcomes broken out by warehouse user. The right shape for chargeback reports, abuse detection, and capacity planning.

Every endpoint returns JSON in a shape designed to load into a BI tool without further reshaping. See the analytics API reference for fields, types, and pagination.

Authenticate with a personal access token

Custom-report pipelines don't run in the App, so they need a non-interactive credential. Mint a personal access token in the App's API explorer and scope it to read-only access on the analytics endpoints. See Create a personal access token and Scope a token for the steps.

Token scope, in plain language for this use case:

• Method: GET only.
• Path: the analytics endpoints you'll call.
• Tenant: a single tenant (or all your tenants, if your report spans them).
• Account: the account whose tenants you're reporting on.

Pull a daily summary

A minimal end-to-end pull, using curl:

curl -H "Authorization: Bearer $AIRBRX_PAT" \
  "https://api.airbrx.ai/analytics/tenants/<tenant-id>/daily?from=2026-04-01&to=2026-04-30"

The response is a JSON array, one object per day in the range. Each object carries the cache outcome counts and the estimated savings field that powers the App's savings tile.

Load into a BI tool

The analytics endpoints return small payloads compared to warehouse extracts — a year of daily data fits comfortably in memory. Two practical patterns:

• Direct pull. Most BI tools (Power BI, Tableau, Excel) can consume JSON from an authenticated REST endpoint. Configure the source with the PAT as a bearer token and a refresh schedule that suits your cadence.
• Land in warehouse first. Pull on a cron job, write to a table in your existing warehouse, and report against the table. This is the right pattern if you want to join Airbrx traffic data against warehouse-side context (cost units, departments, datasets).

Alerting examples

• Hit-rate floor. Page if the daily hit rate drops below a tenant-specific threshold for two consecutive days. Catches rule drift faster than the human eye on the dashboard.
• Spend ceiling. Page if estimated weekly savings drops by more than a fixed amount week-over-week. Often the first signal that a BI tool stopped routing through the Gateway.
• Per-user volume spike. Notify when a single user runs more than N statements in an hour. Catches runaway scripts before they pile up warehouse spend.

What's not on the analytics API

Per-statement detail isn't on the analytics endpoints — those endpoints are for aggregates. If your report needs per-statement data, the App's traffic page is the surface and the underlying endpoints are part of the main admin API.

Where to go next

• Analytics API reference — endpoint shapes and parameters.
• Scope a token — least-privilege scoping for a pipeline PAT.
• Read the dashboard — the metrics the analytics API is built from.